RE: [PHP-DEV] wacky object idea

Stanislav Malyshev wrote: > > 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. > It's more for the error test case. if ($ob->methodThatMightFail()) { doStuff(); } else { handleError(); } However, the alternative, which could be: $ret = $ob->methodThatMightFail(); if (isobject($ret) && $ret->toBoolean()) { doStuff(); } else { handleError(); } is just more verbose and typo-prone, where it doesn't need to be. Ideally, I'd like to do: try { $ob->methodThatMightFail(); doStuff(); doMoreStuff(); doEvenMoreStuff(); } catch (whatever) { handleError(); } > 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? Well ... yes. In the sense that the library will illustrate how to use this implicit handling. If people never bother implementing PEAR objects, then it'll just 'work', much like how you never need to figure out Perl's makemaker unless you are making makefiles (try saying that very fast 10 times) > > 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. > Agreed. This is all on the assumption that they _dont_ want to pass an error handler with every function call, but just parse the return values. > 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. > All classes _are_ equal. The default case is to evaluate to true. You can set it to evaluate to false, or some other expression. > 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. > I'm perhaps revealing my C++ background here, but well-designed coercion leads to far more readable code. Especially with stuff like complex numbers or matrix manipulation, it simply looks clearer when you can effectively write 'add complex number a to complex number b, and return me a complex number c'. It contributes to the black-box'ness of your complex number libraries. Of course, when badly designed code hits the road, you have a nightmare untangling it. I don't see how this is different from some PHP code I've seen, which just gets into a mess of mixing the presentation layer with the application layer, has masses of global variables flying around, etc. Should you remove the global functionality because it can be misused? One thing I really like about PHP though, is the fact that it hasn't gotten overcomplicated like Perl, and that generally there is only one or two ways to do something. With that in mind, adding language constructs is probably a bad idea. Anyway, ultimately all I would really like for my own PHP work is a nice set of reusable code modules, like Perl's CPAN. Whatever helps to make them as easy to reuse and package up, would really make me and my fellow developers here very very happy! (be that the above, or something like exceptions, or the syntax that Stanislav pointed out) Best regards, -- Anil Madhavapeddy, <anil@recoil.org>