Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63695
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <508D9978.3020601@garfieldtech.com>
Date: Sun, 28 Oct 2012 15:45:44 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <508A67E6.2000405@zerocue.com> <508C9AAA.7090508@garfieldtech.com> <508C9CEC.7070403@garfieldtech.com> <508CADBF.50407@zerocue.com>
In-Reply-To: <508CADBF.50407@zerocue.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: larry@garfieldtech.com (Larry Garfield)

See, I'm not convinced that "everyone would agree that #1 [just some 
syntax candy] is definitely not right".  From the discussion here, it 
seems like some are still thinking of it that way.

If they are supposed to be a 3rd thingie, and the only relation to data 
members as we've known them is that they have the same external syntax, 
then IMO we should make them as distinct as possible, everywhere.  New 
keyword, separate reflection pipeline, the works.  That then means that 
the implementation detail of "public $baz { get() {return 'meep'; } 
causes the creation of public function __get_property_meep()" should not 
be exposed, anywhere, and that method should not show up in reflection, 
since it doesn't really exist, it's just an implementation detail.

It's the "depending on how you look at it, you may or may not get to see 
implementation details leak" problem that I think is the worst case 
scenario.

--Larry Garfield

On 10/27/2012 10:59 PM, Clint Priest wrote:
> Hey Larry,
>
> Glad you chimed in here on this.  I my opinion (author of thingy), 
> they are separate and distinct from data members.  More specifically 
> they are getter and setter code that is called when the property is 
> accessed.
>
> Using your example:
>
> echo $obj->baz; // executes the code "return $this->baz;"
>
> and
>
> $obj->baz = 4;  // executes the code "$this->baz = $value;"
>
> So from the perspective of the user of the class, they are just 
> "properties" but internal to the class they are implemented with 
> methods and code.
>
> I think everyone would agree that your #1 is definitely not right, 
> however I believe there is not consensus on whether or not these *are* 
> different from properties.  To the consumer of the class, they are no 
> different than properties, to the author of the class they are very 
> different.
>
> On Saturday, October 27, 2012 9:48:12 PM, Larry Garfield wrote:
>> On 10/27/2012 09:38 PM, Larry Garfield wrote:
>>> 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 
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> 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
>>
>> Addendum: If model 2 (third distinct thingie) is how I'm supposed to
>> be thinking of them, then perhaps an additional keyword is needed to
>> help drive that point home.  Vis:
>>
>> class Foo {
>>   // Data member, directly accessible.
>>   public $bar;
>>
>>   // Clearly a different type of thingie than $bar.
>>   public property $baz {
>>     get() { return $this->baz; }
>>     set($value) { $this->baz = $value;}
>>   }
>>
>>   // A method as we know and love them.
>>   public function beep() {}
>>
>> }
>>
>> Of course, that should only be used if the mental model is that
>> they're a distinct thingie.  If it's just syntactic sugar (again,
>> mental model, not implementation), then a new keyword is a bad idea.
>>
>> --Larry Garfield
>>
>
> -- 
> -Clint
>
>