Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84475
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heybigname.com designates 74.125.82.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.54fdaa02.79838cb2.941f@Mikes-iMac.local>
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>
Date: Mon, 9 Mar 2015 15:11:31 +0100
Message-ID: <CA+FrEoKM0+8JNKw=zzbupRxiURoSYiBNR-eSah9emXLJOZdzpg@mail.gmail.com>
To: Mike Dugan <mike@dugan.io>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0438938796d7850510db9db9
Subject: Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC
From: shawn@heybigname.com (Shawn McCool)

--f46d0438938796d7850510db9db9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I guess that if I thought that PHP would change its scoping, I would have
tried for that.

On Mon, Mar 9, 2015 at 3:11 PM, Mike Dugan <mike@dugan.io> wrote:

> Why not use regular variable naming ($foo) and check the object for
> accessible instance vars before looking for locally scoped vars? I=E2=80=
=99ve no
> idea how the community would feel about it, but that might be a feasible
> approach to getting rid of $this->
>
> --
> Mike Dugan
> mike@dugan.io
> http://dugan.io
>
> On March 9, 2015 at 10:00:03 AM, Shawn McCool (shawn@heybigname.com)
> wrote:
>
> There's a cultural disposition against re-purposing a symbol from one
> major version to the next. Let's consider that as fact and move on.
>
> If I wanted to provide syntactic sugar to replace a symbol with $this-> s=
o
> that our code can become more expressive if we choose to use it, how woul=
d
> you recommend implementing that?
>
> @ is not going to be a _real_ option. But what about..
>
> :number =3D $number;
>
> :add(:number, $number);
>
> or some other character?
>
>
>
> On Mon, Mar 9, 2015 at 2:56 PM, Mike Dugan <mike@dugan.io> wrote:
>
>>   Sure, they should be separated into two equally impossible to pass
>> RFCs.
>>
>>  Just a suggestion based on what I=E2=80=99ve seen here before :)
>>
>> However, do you see a reasonable alternative way to achieve this type of
>> improvement?
>>
>>
>> I=E2=80=99m not sure if you mean the syntax in general or more specifica=
lly the
>> declare-with-$ / use-with-@ issue I took with it?
>>
>>  --
>> Mike Dugan
>>  mike@dugan.io
>>  http://dugan.io
>>
>>  On March 9, 2015 at 9:51:20 AM, Shawn McCool (shawn@heybigname.com)
>> wrote:
>>
>>  Sure, they should be separated into two equally impossible to pass
>> RFCs. However, do you see a reasonable alternative way to achieve this t=
ype
>> of improvement?
>>
>> On Mon, Mar 9, 2015 at 2:48 PM, Mike Dugan <mike@dugan.io> wrote:
>>
>>>  Shawn & Stellan,
>>>
>>> (Apologies if this gets delivered twice, had to confirm myself on the
>>> mailing list again)
>>>
>>> Agreed, @ shouldn=E2=80=99t be repurposed as a macro (or anything). Tha=
t would
>>> lead to a huge amount of confusion for quite a while, but especially du=
ring
>>> the early days of 7. I=E2=80=99m also not a fan of declaring the field =
with dollar
>>> sign prefix but using it with an @ prefix (or any other prefix for that
>>> matter).
>>>
>>> These should probably be separated into two separate RFCs -
>>> deprecating/removing @ error suppression, and pending that one being
>>> accepted the @ instance var macro could then be sent along.
>>>
>>>  --
>>> Mike Dugan
>>>  mike@dugan.io
>>>  http://dugan.io
>>>
>>> On March 9, 2015 at 9:32:23 AM, Stelian Mocanita (stelianm@php.net)
>>> wrote:
>>>
>>>  Hi Shawn,
>>>
>>> My opinion is that even though the "@" operator should be deprecated in
>>> further along the line removed, it should not be repurposed for anythin=
g,
>>> it has too much legacy imho.
>>>
>>> While a shortcut might be a good idea, I personally favour the $this->v=
ar
>>> syntax just for muscle memory if nothing else.
>>>
>>> Stelian
>>>
>>> On Mon, Mar 9, 2015 at 11:54 AM, reeze <reeze@php.net> wrote:
>>>
>>> > Hi,
>>> >
>>> > On 9 March 2015 at 17:43, Shawn McCool <shawn@heybigname.com> wrote:
>>> >
>>> > > I've never submitted an RFC. Whether or not you're interested in th=
e
>>> > > feature, please consider giving me feedback on the RFC itself so
>>> that I
>>> > can
>>> > > better understand how to succeed in the process.
>>> > >
>>> > > =3D=3D=3D=3D=3D=3D PHP RFC: Instance Variable Sugar =3D=3D=3D=3D=3D=
=3D
>>> > > * Version: 0.1
>>> > > * Date: 2015-03-09
>>> > > * Author: Shawn McCool, shawn@heybigname.com
>>> > > * Status: In Discussion
>>> > >
>>> > > =3D=3D=3D=3D=3D Summary =3D=3D=3D=3D=3D
>>> > >
>>> > > In order to access instance variables, one must use the `$this->`
>>> prefix.
>>> > > The problem with this is that it reduces expressiveness in the
>>> language
>>> > and
>>> > > increases the amount of unnecessary decoration, reducing readabilit=
y.
>>> > >
>>> >
>>> > This might decrease readability, since we already comfortable with th=
e
>>> > syntax $this->something, in my opinion
>>> >
>>> >
>>> > > This RFC proposes a single character syntax sugar form of `$this->`=
.
>>> > > Instead, an `@` can be used to reference instance variables.
>>> > >
>>> > > The @ replaces the normal $ variable prefix.
>>> >
>>> >
>>> > > =3D=3D=3D=3D=3D Example =3D=3D=3D=3D=3D
>>> > >
>>> > > <file php MyClass.php>
>>> > > <?php
>>> > > class Addition {
>>> > > private $number
>>> > >
>>> > > public function __construct($number) {
>>> > > @number =3D $number;
>>> > > }
>>> > >
>>> > > public function original() {
>>> > > return @number;
>>> > > }
>>> > >
>>> > > public function addTo($amount) {
>>> > > return @number + $amount;
>>> > >
>>> >
>>> > this is a BC break. this is the same as constant number + $amount. so
>>> this
>>> > syntax is not feasible.
>>> >
>>> >
>>> > > }
>>> > > }
>>> > > </file>
>>> > >
>>> > > =3D=3D=3D=3D=3D Backwards Compatibility =3D=3D=3D=3D=3D
>>> > >
>>> > > Leave `$this->` available.
>>> > >
>>> > > =3D=3D=3D=3D=3D Proposed PHP Version(s) =3D=3D=3D=3D=3D
>>> > >
>>> > > This is proposed for the next PHP x, currently PHP 7.
>>> > >
>>> > > --
>>> > > Shawn McCool | Big Name
>>> > > shawn@heybigname.com
>>> > > heybigname.com
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Reeze Xia
>>> > http://reeze.cn
>>> >
>>>
>>>
>>
>>
>> --
>> Shawn McCool | Big Name
>> shawn@heybigname.com
>> heybigname.com
>>
>>
>
>
> --
> Shawn McCool | Big Name
> shawn@heybigname.com
> heybigname.com
>
>


--=20
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--f46d0438938796d7850510db9db9--