Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84474
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heybigname.com designates 74.125.82.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.54fda677.75a2a8d4.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>
Date: Mon, 9 Mar 2015 15:11:01 +0100
Message-ID: <CA+FrEoJJyKh7x_N0ojL7mgCNgN+3RnS7pCS58rXYoWiUz8MNXg@mail.gmail.com>
To: Mike Dugan <mike@dugan.io>
Cc: Stelian Mocanita <stelianm@php.net>, reeze <reeze@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b8750bece001f0510db9b3c
Subject: Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC
From: shawn@heybigname.com (Shawn McCool)

--047d7b8750bece001f0510db9b3c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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-> so
that our code can become more expressive if we choose to use it, how would
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 specifical=
ly 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 type 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). That=
 would
>> lead to a huge amount of confusion for quite a while, but especially dur=
ing
>> the early days of 7. I=E2=80=99m also not a fan of declaring the field w=
ith 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 anything=
,
>> it has too much legacy imho.
>>
>> While a shortcut might be a good idea, I personally favour the $this->va=
r
>> 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 the
>> > > feature, please consider giving me feedback on the RFC itself so tha=
t
>> 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 readability=
.
>> > >
>> >
>> > This might decrease readability, since we already comfortable with the
>> > 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
>
>


--=20
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--047d7b8750bece001f0510db9b3c--