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" <la...@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 > >
