Hi Mike, On Tue, Jan 03, 2006 at 06:05:31PM -0800, Mike Naberezny wrote: > Hi Andrew, > > I understand your scenario and I agree but I think that this would be > better done in userland by implementing an interface. > > Remember that all of the magic methods do not need to be declared, i.e. you > will always be able to declare __call() without __iscallable(). This is > quite a contrast to implementing an interface such as ArrayAccess, where > offsetSet() and offsetExists() must always be defined in your class. > > The interface enforces a public contract and the behavior of the object is > therefore always guaranteed, which is what you are seeking. In the case of > __iscallable(), its behavior can never have such a guarantee because > programmers may not declare it, so the inconsistency will always exist. > > With that being said, I don't think __iscallable() is a bad idea. My only > reservation with adding it is that it's probably going to become even more > confusing for users to remember which magic methods are available in which > PHP versions. > > Best, > Mike
I whole-heartedly agree with the interface implementation vs. magic methods. My current implementation uses interfaces. It seems that most, if not all, magic method-like behavior might be interfaces down the road. Just curious...what is the party line on that subject? And does such an interface deserve to be part of SPL? Regards, Andrew -- Andrew Yochum Plexpod [EMAIL PROTECTED] 718-360-0879 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
