Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56806
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <CADqTB_i3q6Kmd3LNnd5srkO1-4P6Ak9UtAGekVPhVYP2sfZFfA@mail.gmail.com>
Date: Tue, 6 Dec 2011 09:26:11 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <34B6F836-CC50-4470-AD5F-C6F8C471FC65@gmail.com>
References: <CADqTB_jQoGwqLbSMRUJR97XKSQu+KB3awvudjVGmoDB1gZLgsQ@mail.gmail.com> <9570D903A3BECE4092E924C2985CE4853994C39F@MBX202.domain.local> <b4a2362c6c5ffd4efbca8f8e907054c3@mohiva.com> <CADqTB_i3q6Kmd3LNnd5srkO1-4P6Ak9UtAGekVPhVYP2sfZFfA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
From: will.fitch@gmail.com (Will Fitch)


On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote:

> On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps =
<christian.kaps@mohiva.com>wrote:
>=20
>> Hi,
>>=20
>> I also find this syntax confusing and I think it has a huge WTF =
factor.
>>=20
>> Some thoughts about the syntax:
>> - At the first glance, it isn't clear which visibility the getter or
>> setter has
>> - The extra indentation level makes the code more unreadable
>>=20
>> class Foo {
>>=20
>>   /**
>>    *
>>    */
>>   private $_bar;
>>=20
>>   /**
>>    *
>>    */
>>   public $bar{
>>=20
>>       /**
>>        *
>>        */
>>       set {
>>           if ($bar) {
>>               $this->_bar =3D $bar * 12;
>>           } else {
>>               $this->_bar =3D 0
>>           }
>>       }
>>=20
>>       /**
>>        *
>>        */
>>       private set {
>>           if ($this->_bar =3D=3D=3D null) {
>>               return 0;
>>           }
>>=20
>>           return $this->_bar;
>>       }
>>   }
>>=20
>>   /**
>>    *
>>    */
>>   public function baz() {
>>=20
>>   }
>> }
>>=20
>> - What about type hints?
>>=20
>> I prefer a more AS3 like getter and setter syntax.
>> http://help.adobe.com/en_US/**ActionScript/3.0_**ProgrammingAS3/**
>> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
>> =
WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb<http://help.adobe.com/en_US/Ac=
tionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.ht=
ml#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb>
>>=20
>> Have you read my previous mail =
http://news.php.net/php.**internals/56762<http://news.php.net/php.internal=
s/56762>
>> .
>> I think this syntax fits more to PHP because its similar to the =
already
>> existing(magic) getter and setter syntax.
>>=20
>> What do you think?
>>=20
>> Christian
>>=20
>=20
> I agree with all of those points - the extra indentation looks messy, =
and
> yes, type hints are important. It does fit better with PHP in general.
>=20
> It would be nice to also have support for automatic backing fields in
> addition though - so something simple like this:
>=20
> class BlogPost
> {
>    private $_author;
>=20
>    public get author()
>    {
>        return $this->_author;
>    }
>=20
>    public set author(Person $value)
>    {
>        $this->_author =3D $value;
>    }
> }

I don't like this approach.  All efforts (which I'm currently part of) =
to implement type hinting return values will be compromised.  If you =
want to implement accessors, keep them within a syntax that makes sense. =
 Personally, I support the C# style as much as possible.  Methods are =
already overused for purposes they shouldn't be, so if we're attempting =
to get around __set/get, let's not replace them with more method =
implementations.

>=20
> Could be written like this:
>=20
> class BlogPost
> {
>    public Person $author;
> }
>=20
> Effectively, this shorthand syntax just gives you type-safe properties =
-
> but it refactors nicely, since you can replace it with a full
> implementation of a backing field at any point.
>=20
> (on second thought, I don't like the idea I suggested before - adding =
a
> magical $value in accessors, similar to $this - it's confusing and =
it's
> going to look like an undeclared local variable...)