Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63681
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: <508C9CEC.7070403@garfieldtech.com>
Date: Sat, 27 Oct 2012 21:48:12 -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>
In-Reply-To: <508C9AAA.7090508@garfieldtech.com>
Content-Type: text/plain; charset=ISO-8859-1; 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)

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