Hi! > 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.
I think these types are not right. It has nothing to do with internals/userland, it has to do with wanting more magic that work is a complex way while allowing user no knowledge and control over what's going on, or reduced number of simple concepts that interact in a variety of ways. You can say it's Windows model vs. Unix model, if you need monikers. > *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 Again, this insists on the notion that there's such accepted thing as "accessor" in PHP field, which already has a known behavior and set of expectations, and these match exactly the proposal of "invisible". But this is not true at all - only successors existing so far in PHP are regular perfectly visible methods. So if you expect to see an accessor, you expect to see __get. If you appeal to natural expectations of PHP user, you can not argue it is "for accessors to be accessors", because PHP has never had anything like you proposed, and there's no any accepted definition of "accessor" that implies what you are implying. > 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 Please do not insult the intelligence of PHP users. They are not some mindless creatures that given property Hours, previous existence of __get and __getHours can not figure out what's going on, even after being told of the new accessors feature (since they're using it in the code). They won't be confused. Nobody knowing how to program a hello-world would. This mythical easily-confusable users do not exist, but if they did, they'd just not use reflection because it'd be too confusing for them anyway. > than specially formatted and called methods on the class. This can be > understandable because you want all information available to you. You This has very little to do with information available. This has everything to do with > 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. You can very easily handle the error in the same handler that you look for setter, this is not an issue at all. In general, error messages have very little to do with the whole thing. If the error messages is the thing you're worried about - it should be trivially easy to fix, since all access will go through object handlers anyway, and the object handler would decide to throw the error - so you'd be able very easily to issue any error message you like. > *Unfortunately 80 to 95% of all people who use PHP are of the first type.** Not really. There are a lot of programmers that aren't Windows type, and prefer simple interfaces to ones with a lot of complicated magic. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
