Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.110.135 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56F14572.701@gmail.com> <56F15EF5.80006@telia.com>
 <56F16023.1010002@gmail.com>
 <CAPhkiZxYwXKLp8ASkjiwXgzDtjKxJ8rYROCM-t=8sU5=efhg2w@mail.gmail.com>
 <CAPhkiZwOJOkNu4N=h+wQRX4w8-KV=zg9x4khhLRLu199YcqZxw@mail.gmail.com>
 <CABDNdAGh4OjkkEQim6oYK=sZ=zj1Q==HzE=SLJ1E8=a=ku1DqA@mail.gmail.com>
 <CY1PR0201MB17863E4B9D9F53151A900DCDBF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
 <CAL=_i_mNwmpg0PWmrm3nTZxn6s33u2QUzavk8w0Fk1OGvbWJtA@mail.gmail.com>
 <CY1PR0201MB1786AAFDC6170AB1585CA7F5BF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
 <CY1PR0201MB17867DAC10D401EE9EC49CBCBF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
 <CAL=_i_knwzrcXdx1k4ii8YKzrgaREBFcHYGC9ZV_J05ZWVWmzg@mail.gmail.com>
 <56FC4ED6.6050701@telia.com>
 <CAL=_i_ksOzCV1SUtB2jwSYPm1SL2y3jy43+JSZ3k6KRywsizUg@mail.gmail.com>
 <56FCE6C9.1050302@zend.com>
 <CAL=_i_kx=94AFi=+iU-+EaqWms_0OfuUHgoOFZQtV1xS98tGWQ@mail.gmail.com>
CC: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>, Phil Sturgeon
	<pjsturgeon@gmail.com>, Krakjo <krakjoe@php.net>, PHP internals
	<internals@lists.php.net>
Message-ID: <56FD1D38.7050504@zend.com>
Date: Thu, 31 Mar 2016 15:51:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAL=_i_kx=94AFi=+iU-+EaqWms_0OfuUHgoOFZQtV1xS98tGWQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------050807080204060508050603"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2016 12:51:19.4784 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1791
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: dmitry@zend.com (Dmitry Stogov)

--------------050807080204060508050603
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit



On 03/31/2016 03:40 PM, Joe Watkins wrote:
> Morning Dmitry,
>
> > This should be a error. I also think, that "public" might
> > be omitted, and it should be possible to write "int $bar, $foo"
>
> Omitting public might be nice, but also totally separate, you should 
> be able to omit it for untyped properties too.

Right. We may use "var $a, $b;".

>
> > You say - C, C++, Java, HHVM, etc - all made worse decision? OK
>
> No. C, C++, C#, and Java had a different decision to make.
>
> [public] int foo, bar;
>
> It is obvious that bar is an int in any of those languages precisely 
> because it necessarily has a type.
>
> Why we should jump to the same conclusion, in a system where 
> properties do not necessarily have types is not clear to me.

Just not to confuse programmers with uncommon grouping behavior.

Thanks. Dmitry.

>
> Cheers
> Joe
>
>
>
> On Thu, Mar 31, 2016 at 9:58 AM, Dmitry Stogov <dmitry@zend.com 
> <mailto:dmitry@zend.com>> wrote:
>
>
>
>     On 03/31/2016 11:34 AM, Joe Watkins wrote:
>>     Morning,
>>
>>     > Given that public is implied for all properties above there
>>     > is a value in having the same rule for type.
>>
>>     public $bar, int $foo;
>>
>>     What does this mean?
>>
>>     If it's not an error, what does this mean ?
>
>     This should be a error. I also think, that "public" might be
>     omitted, and it should be possible to write "int $bar, $foo".
>
>>
>>     public $bar, int $foo, $qux;
>>
>>     If it's an error, why is it an error ?
>>
>>     Both of these examples are just as ambiguous as
>>
>>     public int $foo, $bar, $qux;
>
>     You say - C, C++, Java, HHVM, etc - all made worse decision? OK...
>
>>
>>     Access modifiers are assumed to apply to all declarations in a
>>     group, because that's what grouping is actually for.
>>
>>     We don't need to make grouping about types, we need to make type
>>     declarations unambiguous.
>
>     Very strange grouping decision.
>     At least your opinion is questionable and except for other
>     languages, you see a number of opponents on @internals.
>
>     Thanks. Dmitry.
>
>
>>
>>     > Anyway, in Hack following syntax passes: https://3v4l.org/3tUu9
>>
>>     Hack does not consider types implicitly nullable.
>>
>>     <?hh
>>     class Foo {
>>       public int $int = null;
>>       public stdClass $std = null;
>>     }
>>
>>     things.php:3:10,12: Wrong type hint (Typing[4110])
>>       things.php:3:10,12: This is an int
>>       things.php:3:21,24: It is incompatible with a nullable type
>>     things.php:4:10,17: Wrong type hint (Typing[4110])
>>       things.php:4:10,17: This is an object of type stdClass
>>       things.php:4:26,29: It is incompatible with a nullable type
>>
>>     <?hh
>>     function foo(int $int = null, stdClass $std = null) {}
>>
>>     things.php:2:18,21: Wrong type hint (Typing[4110])
>>       things.php:2:14,16: This is an int
>>       things.php:2:25,28: It is incompatible with a nullable type
>>     things.php:2:40,43: Wrong type hint (Typing[4110])
>>       things.php:2:31,38: This is an object of type stdClass
>>       things.php:2:47,50: It is incompatible with a nullable type
>>
>>     HHVM doesn't care about types ... we don't compare our type
>>     system to that ...
>>
>>     Cheers
>>     Joe
>>
>>     On Wed, Mar 30, 2016 at 11:10 PM, Björn Larsson
>>     <bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>> wrote:
>>
>>         Den 2016-03-30 kl. 05:16, skrev Joe Watkins:
>>
>>             Morning Dmitry,
>>
>>                 1) static typed properties are prohibited. why?
>>
>>             Feels like that's a separate feature, static properties
>>             are as good as
>>             makes no difference, global variables.
>>
>>             Instance properties, the engine has good control over
>>             their manipulation,
>>             for static properties it doesn't, it's not impossible,
>>             but feels separate.
>>
>>         Good that it's clarified in the RFC since one could easily
>>         believe that it's possible to set type for a static property.
>>
>>
>>                 2) The handling of multiple properties in the same
>>                 declaration statement
>>
>>             is inconsistent.
>>
>>             This feels consistent to me .. in other languages where
>>             the type is
>>             required, it makes sense to assume the type is implied.
>>
>>             In a language where the type is optional, public int
>>             $foo, $bar; feels
>>             ambiguous to me.
>>
>>         Given that public is implied for all properties above there
>>         is a value in having the same rule for type.
>>
>>
>>                 3) We already have nullable arguments without any
>>                 special syntax. We
>>
>>             should reuse the similar approach for properties.
>>
>>             Making properties implicitly nullable defeats the object
>>             of trying to
>>             provide type safety.
>>
>>             Null is never a valid value for a typed property, if it
>>             were, you would
>>             never be sure of the type of variable you are getting,
>>             and would have to
>>             litter your code with is_null checks.
>>
>>         Maybe good to clarify difference towards default parameters?
>>         Anyway, in Hack following syntax passes: https://3v4l.org/3tUu9
>>
>>
>>                 I think it might be better to implicitly initialize
>>                 them according to
>>
>>             type (if default value is not provided): bool by false,
>>             int by 0, double by
>>             0.0, string by "" (interned), array by [] (immutable),
>>             objects by NULL
>>             (always nullable).
>>
>>             Definitely not, lying about the default value isn't a
>>             good idea.
>>
>>             There are times when 0 is as valid as 1, or any other
>>             value for an int.
>>
>>             If you have declared that you know the type of the
>>             property, and you write
>>             code that accesses that property before there is any
>>             possible chance you
>>             have set the property, that's a programming error.
>>
>>             We should not hide that error with a default value, or by
>>             allowing the
>>             engine to return null.
>>
>>         Don't have a strong opinion on this one, can see both views.
>>         Maybe a bit affected by programming in Java recently, having
>>         a slightly more positive attitude towards default values ;-)
>>
>>         Regards //Björn Larsson
>>
>>
>
>


--------------050807080204060508050603--