That's why I think they shouldn't even be visible to users, they aren't
relevant to them and in fact it could mis-lead them into thinking that
they could simply define __getHours() and expect $foo->Hours to call
it, which it wouldn't.
To me, the bottom line is, the fact that there are methods defined by
accessors is an engine detail and not something that should be exposed
to the user.
As for the __set_state() issue, I can see the need to change the
pattern of method naming, I'd be amenable to anything.
Everyone okay with __get_prop_hours() naming convention then?
On Saturday, October 27, 2012 3:01:39 AM, Patrick Schaaf wrote:
- i.e. name them __prop_get_xxx, __prop_set_xxx, and so on.
I think it'd more natural to make it __set__PROPNAME. Though __set_state
is a static method, so maybe we can live with it - except that you won't
be able to declare property named $_state.
Needing an "except" is inelegant, if it can be avoided up front.
Also, having __prop_get_XXX etc. is a bit more descriptive to somebody
later "wondering" what these methods are - prop alludes to properties,
which is what the methods are about. I can already see the stack overflow
subject, "what are these __prop methods in new PHP" :)
best regards
Patrick
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
