Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91818
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <1458149992.3969.2.camel@kuechenschabe>
 <BLU436-SMTP1394648F9BABA2FA74BFC4DE28A0@phx.gbl>
 <1458151531.3969.8.camel@kuechenschabe>
 <BLU436-SMTP2092DD6AFBC93D83397A3C7E28A0@phx.gbl>
 <1458153695.3969.16.camel@kuechenschabe> <3F.70.02405.6803BE65@pb1.pair.com>
Message-ID: <56F01545.8080008@gmail.com>
Date: Mon, 21 Mar 2016 15:37:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <3F.70.02405.6803BE65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: rowan.collins@gmail.com (Rowan Collins)

Andrea Faulds wrote on 17/03/2016 22:32:
> Hi Johannes,
>
> Johannes Schlüter wrote:
>> On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote:
>>>
>>> Eih, only to typed properties. Everything else would be insane ;-)
>>> Sorry for being imprecise.
>>
>> Ok, quite a lot better, but still weird difference to the language.
>>
>>
>> There's a notable amount of places where references are being used and
>> often users aren't aware. (Binding parameters in database queries, in
>> order to support OUT parameters, comes to mind, many array functions
>> take an array, some functions use it to report error codes, ...)
>>
>> I guess this will be a famous support issue.
>>
>> And yeah, I'd love to "fix" all those places and get rid of the
>> references, but BC ... it's quite massive :-)
>>
>
> Disallowing references here might make users more aware of which 
> functions take parameters by reference, and avoid accidentally 
> modifying values. So this part of the RFC might be a good thing. 


I'm not a fan of this kind of side-effect coupling - "because this 
feature is new, it also triggers other new features". If you want no-ref 
properties, that should be something a user chooses directly, e.g. 
"class Foo { public noref $bar; }".

Adding an "array" typehint to something absolutely should not prevent it 
being passed to sort(), IMHO.

Perhaps we could have an IS_TYPED_REF zval? You don't actually need to 
store the desired type, only assert that the old and new reference 
targets are of the *same* type when performing assignment.

Regards,
-- 
Rowan Collins
[IMSoP]