Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92036
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.155 cause and error)
To: Joe Watkins <pthreads@pthreads.org>, Dmitry Stogov <dmitry@zend.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <BLU436-SMTP2092DD6AFBC93D83397A3C7E28A0@phx.gbl>
 <1458153695.3969.16.camel@kuechenschabe> <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>
Cc: Phil Sturgeon <pjsturgeon@gmail.com>, Krakjo <krakjoe@php.net>,
 PHP internals <internals@lists.php.net>
Message-ID: <56FC4ED6.6050701@telia.com>
Date: Thu, 31 Mar 2016 00:10:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAL=_i_knwzrcXdx1k4ii8YKzrgaREBFcHYGC9ZV_J05ZWVWmzg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

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