Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63723
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
Message-ID: <509040EA.3030507@garfieldtech.com>
Date: Tue, 30 Oct 2012 16:04:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <508A67E6.2000405@zerocue.com> <508C9AAA.7090508@garfieldtech.com> <CAH-PCH53r_d-Qf_c=WuyGBagsN49zYXEY64QCuidq9yNmhe8bQ@mail.gmail.com>
In-Reply-To: <CAH-PCH53r_d-Qf_c=WuyGBagsN49zYXEY64QCuidq9yNmhe8bQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: larry@garfieldtech.com (Larry Garfield)

There are still use cases for __get(), when the list of internal 
properties is dynamic.  We're actually leveraging that for Drupal 8's 
entity system.  Removing it would be a big problem. :-)

But that still doesn't resolve the mental model question.

--Larry Garfield

On 10/30/12 3:05 AM, Ferenc Kovacs wrote:
> I would say that the proposed accessors is what we should have added back
> then instead of __get/__set . The problem is that now we will have two
> similar (albeit one is an ugly subset of the other) feature which needs to
> co-exists.
> My gut tells me that we should ditch the magic method approach with the
> introduction of accessors and provide easy/automated migration.
> Ofc. that would mean that we need at least one major version.
> My two cents from the sidelines.
> 2012.10.28. 3:39, "Larry Garfield" <larry@garfieldtech.com> ezt írta:
>
>> On 10/26/2012 05:37 AM, Clint Priest wrote:
>>
>>> I'm opening up several new threads to get discussion going on the
>>> remaining "being debated" categories referenced in this 1.1 -> 1.2 change
>>> spec:
>>> https://wiki.php.net/rfc/**propertygetsetsyntax-as-**
>>> implemented/change-requests<https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests>
>>>
>>> ------------------------------**------------------------------**
>>> ------------
>>> Some people are in favor of the internal functions being generated by an
>>> accessor declaration should be invisible and non-callable directly. Others
>>> are in favor of leaving them visible and callable.
>>>
>>> *Type 1 ( Userland Programmer )**
>>> *
>>> As a userland programmer, someone who cares nothing for "how" php works,
>>> only how their own code works. If they define an accessor they expect to
>>> see an accessor, reflection should reflect that there are accessors and no
>>> other "methods" they did not explicitly define. If they were to reflect on
>>> all of the methods of their class and see a number of __getHours() they may
>>> be confused as to why or where this function came from. From their
>>> perspective, they have defined an accessor and "how" that accessor works on
>>> the inside is of no importance to them and only seeks to complicate or
>>> confuse matters when they are exposed to these "implementation details" of
>>> the php language its-self. If you tried to set a value such as $obj?abc = 1
>>> through an accessor which could not be set, you would probably want to see
>>> an error like: Warning, cannot set Class?abc, no setter defined.
>>>
>>> *Type 2 ( Internals Programmer )**
>>> *
>>> As an internals programmer, you want nothing hidden from you. If an
>>> accessor implements special __getHours() methods to work its magic, then
>>> you want to see them, you want to call them directly if you so choose. In
>>> effect you want nothing hidden from you. In this case you probably don't
>>> even want Reflection to reflect accessors as anything different than
>>> specially formatted and called methods on the class. This can be
>>> understandable because you want all information available to you. You would
>>> probably not be confused if you wrote $obj?abc = 1 and got back an error
>>> like "Fatal Error: Class->__setAbc() function does not exist.
>>>
>>> *Unfortunately 80 to 95% of all people who use PHP are of the first
>>> type.**
>>> *
>>> Revealing these internal matters to them would only leave them confused,
>>> possibly frustrated and likely asking about it to the internals mailing
>>> list to answer (repeatedly).
>>> ------------------------------**------------------------------**
>>> ------------
>>>
>>> Thoughts?
>>>
>>>
>> Speaking as a user-land programmer that's been following this thread, but
>> hasn't been able to jump in yet due to the high volume of comments...
>>
>> What's unclear to me is what my mental model should be for this new
>> syntax.  That's important for informing how it should be exposed to me.
>>
>> 1) Should I have a mental model of this being some syntax candy on top of
>> existing properties?  Vis, this is just a short-hand for bean-style
>> classes?  By Bean style, I mean Properties that would be public but aren't
>> because Public Is Bad(tm), so instead we have getX()/setX() for every
>> property, so that we can still use the object like a struct rather than an
>> object but still say we're using methods even though we've just
>> reimplemented public properties with more verbose syntax.  (Note: Yes, I
>> know that's a rather harsh and judgmental description.  I happen to firmly
>> dislike Bean-style objects.)
>>
>> 2) Should I have a mental model that these fancy-pants properties are some
>> different third thingie on objects, distinct from traditional data members
>> and methods?
>>
>> Right now I'm not sure which mental model I'm supposed to use, and I get
>> the sense that there's no clear consensus on that question yet. That, I
>> think, is the key question, and will inform how things like Reflection
>> should expose data about this new syntax.
>>
>> For instance, if model 2 is how I'm supposed to be thinking, then I'd
>> expect I'd need a third reflection object for getting things off of an
>> object/class, separate from traditional data members and methods.  Then
>> it's consistently a third thingie.  If, however, I'm supposed to think of
>> it as just a short-hand syntax for writing a bean, then I'd expect it to be
>> presented to me as if I'd hand-written all of the stuff that this syntax is
>> emulating.  Vis, methods show up as methods, and anything I'd be able to
>> read/write directly without going through an intermediary method should
>> show up as a property just as it does now.
>>
>> Note: I'm speaking here of the mental model of the user, which does not
>> necessarily have any relationship to the implementation details.  If I'm
>> "supposed" to think of it as a third thingie, it doesn't matter that it may
>> be implemented internally as syntactic sugar.  It should be presented to me
>> as a third thingie, consistently, with the engine internal implementation
>> details completely irrelevant.  (Which means they can be changed later if
>> needs be.)
>>
>> I don't know which mental model is intended, nor which one would be
>> better, but that is, I believe, the question that should inform the rest of
>> these discussions.
>>
>> --Larry Garfield
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>