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
