Hi! > users control. Actually, both approaches are exactly the same, the > only difference is whether we additionally put the accessor function > into the method table or whether we do not.
They may be almost the same technically, but very different conceptually. Your approach means we introduce new complex concept of not-quite-method, which can be called only in some special circumstances, has special handling by compiler, backtraces, reflection, tools, etc. and requires people to learn this new concept and be always aware of it to be able to correctly operate it. My approach is that you just have another magic method, which we already have plenty in PHP, and does not require any new concepts introduced, and works very similar to existing access magics. > I still fail to see where you see complexity come into the picture. Described above. You want to introduce new entity into PHP called "accessor", which looks like PHP method, but lives outside of the PHP method table, is not callable by regular means (though might be callable by special means, but you have no way to use methods' reflection to know if such call would succeed or not) and requires special considerations. This is more complex than using already existing concepts, by definition - more concepts is more complex than less concepts. > You have mentioned inheritance checking, but from what I see the > functions doing the inheritance check take generic zend_function*s, so > they wouldn't have a problem dealing with code not in the method > table. The same applies to pretty much everything else too. After all, > there *is* a reason why we have abstractions in the engine ;) They won't have a problem. They won't deal with these not-quite-methods. That's exactly the problem - we already have mechanism of dealing with inheritance, and you propose to introduce another one to deal with additional complexity of methods not in method table. > To me the situation is as simple as this: I declared a get accessor > for $foo. I did not declare the method __getfoo(). So why is that > method there? This in not simple. You know what "accessor" is. The other 100% of PHP users have no idea what "accessor" is. They know what methods are, they know what magics are. So if I tell them "we have extensions of __get that allow you to do __getFoo" - they instantly know what's going on. If I tell them "we have accessors" - they'd have to go and read the manual to understand what is going on and which additional restriction you placed on them in order to force them into your preconception of "accessor". > It seems really pointless, counter-intuitive and hacky to me to > automatically create methods that do not actually exist (not under > that name at least). What you mean by "do not actually exist"? Of course they exist, that's the whole point. You will be running them, how they don't exist? You just want hide their existence by introducing a bunch of complex checks all over the engine under the premise that showing the user the real methods in function table would "confuse" them. It won't. The only thing it would do is contradict your idea that there's some definition of "accessors" that requires them to not be methods. I see no reason for such definition. It is an option, but having them as methods is an option too, and in my opinion a much better one. -- 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
