Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
Sender: stelian.mocanita@gmail.com
In-Reply-To: <CAJW__o3rPubdmmxdL0sNhTf+AcizFVhbLcMByPM08njjaBtTsg@mail.gmail.com>
References: <CA+FrEoKBhRErj2i_rSyeOyTBHAYw-OxjMKPGz6dDhayCMeWsKQ@mail.gmail.com>
	<CAG1chorE4VwMJ0d=hs5pf8T-5z915fwv9uJvkRQ-NNnhKJPzaA@mail.gmail.com>
	<CAMc0WS6SVsnQQ6pSzUeCpDRzEwBZFeos1CwXMxxzHF3YjR5txA@mail.gmail.com>
	<etPan.54fda4b0.333ab105.941f@Mikes-iMac.local>
	<CA+FrEoL1tOuExW8wPGiO1kMa8pGa72NR3zgxsOwUuS0bcr4BuA@mail.gmail.com>
	<etPan.54fda677.75a2a8d4.941f@Mikes-iMac.local>
	<CA+FrEo+Hrbjzsw7tOBXv=WOLQU0JzOm4wLrGaYMXDP33G=O02w@mail.gmail.com>
	<etPan.54fdaa02.79838cb2.941f@Mikes-iMac.local>
	<CA+FrEoKM0+8JNKw=zzbupRxiURoSYiBNR-eSah9emXLJOZdzpg@mail.gmail.com>
	<CAJW__o3rPubdmmxdL0sNhTf+AcizFVhbLcMByPM08njjaBtTsg@mail.gmail.com>
Date: Mon, 9 Mar 2015 15:37:46 +0100
Message-ID: <CAMc0WS7J3xZZwhX0g=g7wJP6qEKVHTiXNRRYUcQUw4RWnNR0hw@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Shawn McCool <shawn@heybigname.com>, Mike Dugan <mike@dugan.io>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3cf28449a280510dbfacf
Subject: Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC
From: stelianm@php.net (Stelian Mocanita)

--001a11c3cf28449a280510dbfacf
Content-Type: text/plain; charset=UTF-8

On top of the cultural disposition, there is also the fact that things
should not be removed from the language without deprecating them, so at
best 7.0 would emit and E_DEPRECATED for the usage of "@".

- Stelian

On Mon, Mar 9, 2015 at 3:31 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Hi
>
> 2015-03-09 15:11 GMT+01:00 Shawn McCool <shawn@heybigname.com>:
> > I guess that if I thought that PHP would change its scoping, I would have
> > tried for that.
>
> Well take this code into consideration:
> <?php
>  class A {
>    protected $b;
>
>    function c($b) {
>     $b = $b; // does not work
>    }
>
>    function d($d) {
>     $b = $d; // works
>    }
> }
> ?>
>
> A::c() will fail because the parameter $b conflicts with the property
> A::$b, but example works because the parameter is now named $d, and
> therefore making $b available for assignment (should probably
> internally be implemented as a reference to $this->b), but only on
> demand (JIT) to avoid extra memory consumption.
>
> This approach may seem quirky at first, but it doesn't add any new
> syntax but some magic behind the scenes. Although I personally am not
> a huge fan of magic variables like that, it is possible.
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--001a11c3cf28449a280510dbfacf--