Re: wacky object idea

AM>> The added value would be that when end-users make use of PEAR, they have AM>> a much simpler process to check for errors than if the type-coercion AM>> facility wasn't there. Again, I don't see how echo $object is more understandable than $object->Dump(). On the contrary, the former gives user an impression he can do this with any object, which is not true. AM>> subject to a lot of peer review - it would not make anything other than AM>> excellent use of the new functionality, and would provide a good example AM>> of how to use it. Are you really hoping somebody will read source code of the library to understand how it works? AM>> But then how do you signal different types of failure? The AM>> PEAR_Exception object (or subclasses of it) could encode a lot AM>> of error information which you lose if you just return false. Well, if you need so complicated returns, you probably better use by-reference passing or something like this, like libc functions do. Or use some other patent of the same grade. AM>> But if it automatically evaluates to false, that would give you AM>> the best of both worlds. Making a lot of special cases and magic variables is extremely bad design. All classes should be equal, otherwise you create a bad magic. AM>> PS: a lot of people have expressed a dislike of operator overloading - AM>> the above is simply type coercion isnt it? A very very AM>> specific case of overloading, and certainly not the whole thing. If you need this, why don't you do it explicitly? Why do you need language magic? If you know exactly what you need in particular case, just write it. Anyway, if(is_false_object(foo())) is much more readable than if(foo()) because reader should not remember here that some object is magically evauated to false while all other are magically evaluated to true. -- Stanislav Malyshev stas@zend.com http://www.zend.com/ +972-3-6139665 ext.106