Re: wacky object idea

Stanislav Malyshev wrote: >I don't see any added value here. Don't echo it, $object->echo() it, >what's the big difference? Overriding standard opearotrs can lead to a bad >magic easily, when you rapidly lose understanding what's really happening >behind your code. The added value would be that when end-users make use of PEAR, they have a much simpler process to check for errors than if the type-coercion facility wasn't there. Of course you can shoot yourself in the foot with this, but you also allow PEAR code to look much more elegant, and be simpler for the end user to implement. After all, PEAR is part of PHP, and by implication will be subject to a lot of peer review - it would not make anything other than excellent use of the new functionality, and would provide a good example of how to use it. >CH>> if ($obj->methodThatMightFail()) {} >CH>> or >CH>> $res = $obj->methodThatMightFail(); >CH>> if ($res) {} >CH>> >CH>> Instead of: >CH>> $res = $obj->methodThatMightFail(); >CH>> if (is_object($res) && (getclass($res) == 'PEAR_Exception')) { // failed } > >Make method return false on failure. But then how do you signal different types of failure? The PEAR_Exception object (or subclasses of it) could encode a lot of error information which you lose if you just return false. But if it automatically evaluates to false, that would give you the best of both worlds. Also, you are free to return other objects, which would evaluate to true, and still have the simple check above. I'm not sure that adding anything other than boolean and string is a good idea, but those two would be really useful for error-checking and debugging objects, respectively. Any more would probably lead to confusion and bad karma. PS: a lot of people have expressed a dislike of operator overloading - the above is simply type coercion isnt it? A very very specific case of overloading, and certainly not the whole thing. -- Anil Madhavapeddy, <anil@recoil.org>