Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56840
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <CADqTB_j+SsBtfdJzUfnRrR6e9EwStcMQ9uYZteZ_+pLTFeeQEA@mail.gmail.com>
Date: Wed, 7 Dec 2011 13:58:01 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <F2014E57-33A0-4B7F-9EF4-BACEE2A09474@gmail.com>
References: <CADqTB_jQoGwqLbSMRUJR97XKSQu+KB3awvudjVGmoDB1gZLgsQ@mail.gmail.com> <9570D903A3BECE4092E924C2985CE4853994C39F@MBX202.domain.local> <b4a2362c6c5ffd4efbca8f8e907054c3@mohiva.com> <CADqTB_i3q6Kmd3LNnd5srkO1-4P6Ak9UtAGekVPhVYP2sfZFfA@mail.gmail.com> <34B6F836-CC50-4470-AD5F-C6F8C471FC65@gmail.com> <CADqTB_hguOHTQC5VK+yVgKR3gcL9vG8e8Jwtvu00y27FJE5hWw@mail.gmail.com> <C3FA9128-6A49-4A2E-81A7-ED16CB936F57@gmail.com> <CADqTB_j+SsBtfdJzUfnRrR6e9EwStcMQ9uYZteZ_+pLTFeeQEA@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)

I'm saying that when you define an accessor, the body of the get/set =
functionality is contained within get {} and set {}, just like C#.  I'm =
referencing your suggestion to automatic backing fields.  There's no =
need for the backup.

Reflection for accessors should be treated the same as the rest.  Since =
there is a definition for each get and set, =
Reflection{Property/Accessor} should treat invocations of those =
separately, so I agree with that, but Reflection hasn't failed us so =
far. :) =20


On Dec 7, 2011, at 1:33 PM, Rasmus Schultz wrote:

> I have no opinion about how it gets implemented under the hood - I =
thought
> we were just discussing the syntax. I most likely don't know enough =
about
> the innards of PHP it carry on that discussion.
>=20
> But by userspace definitions, are you referring to the fact that =
getters
> and setters would compile down to actual methods? I have no strong =
feelings
> about that one way or the other - as long as the reflection API =
reports
> what was defined in the source code, rather than reflecting the =
underlying
> accessor-methods as actual methods. (something that doesn't seem to be =
true
> for traits...)
>=20
> I don't know if that's meaningful or relevant to you, but I think =
that's
> all I can contribute to that discussion...
>=20
> On Wed, Dec 7, 2011 at 1:11 PM, Will Fitch <will.fitch@gmail.com> =
wrote:
>=20
>> The difference being *where* the functionality gets mapped.  It's not
>> about making something "look like something else", it's about =
requiring
>> more userspace definitions.  Functionality within get {} and set {} =
can
>> (and should IMO) be implemented outside of userspace code.  Whether =
that
>> means another union within op_array or a completely new structure =
mapped to
>> a property zval and bitmap added to the zend_uchar type identifying =
it as
>> an accessor....  I'm saying be creative - don't just implement =
something
>> halfway for the sake of getting it done.
>>=20
>>=20
>> On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote:
>>=20
>>>> if we're attempting to get around __set/get, let's not replace them =
with
>>> more method implementations
>>>=20
>>> I don't understand this argument. Accessors are methods - making =
them
>> look
>>> like something else won't change that fact.
>>>=20
>>> In C#, type-hinted properties with automatic getters/setters =
actually
>>> compile down to two method implementations, while implemented
>>> getters/settings do the same, substituting "value" for whatever is
>> required
>>> to access the auto-implemented backing field.
>>>=20
>>>=20
>>> On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch <will.fitch@gmail.com> =
wrote:
>>>=20
>>>>=20
>>>> On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote:
>>>>=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;
>>>>>  }
>>>>> }
>>>>=20
>>>> 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
>>>>=20
>>=20
>>=20