Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.180 cause and error)
MIME-Version: 1.0
In-Reply-To: <56FCE6C9.1050302@zend.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<3F.70.02405.6803BE65@pb1.pair.com>
	<56F01545.8080008@gmail.com>
	<CAF+90c-Z82kBT18ivvKejD5_dBf=dtbNYN-cZcyO1K=0C1WcLA@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>
Date: Thu, 31 Mar 2016 13:40:49 +0100
Message-ID: <CAL=_i_kx=94AFi=+iU-+EaqWms_0OfuUHgoOFZQtV1xS98tGWQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.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>
Content-Type: multipart/alternative; boundary=001a1143312c7ee2d4052f579253
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: pthreads@pthreads.org (Joe Watkins)

--001a1143312c7ee2d4052f579253
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

> 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.

Cheers
Joe



On Thu, Mar 31, 2016 at 9:58 AM, Dmitry Stogov <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>
> https://3v4l.org/3tUu9
>
> Hack does not consider types implicitly nullable.
>
> <?hh
> class Foo {
>   public int $int =3D null;
>   public stdClass $std =3D 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 =3D null, stdClass $std =3D 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 tha=
t
> ...
>
> Cheers
> Joe
>
> On Wed, Mar 30, 2016 at 11:10 PM, Bj=C3=B6rn Larsson <bjorn.x.larsson@tel=
ia.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 manipulatio=
n,
>>> 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 statemen=
t
>>>>
>>> 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 t=
o
>>> 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>
>> 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, doubl=
e
>>> 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 yo=
u
>>> 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=C3=B6rn Larsson
>>
>>
>
>

--001a1143312c7ee2d4052f579253--