On Mon, 2004-02-16 at 09:35, Andi Gutmans wrote: > Hey, > > Marcus didn't mean it adds complexity to the code but to PHP.
I can't see how it would: For those relying on the built-in base class, it won't change a single thing.
For those wanting their own exception (or to be more correct: _class_) hierarchy (me, for example, or Ferdinand, or - if I understood him correctly - Sterling, which makes three and is therefore more than "one in a million" you mentioned:)) it opens up possibilities and adds flexibility to the language.
Don't take internals@ and their profile as a statistical equal to the PHP community.
Flexibility is a point in which PHP has always been very good: No enforcements on types, classes, solutions. Everyone is welcome to and is actually creating amazing frameworks (PEAR, binary cloud, Horde, to name a few of the big ones) _ontop_ of the core of PHP / the Zend Engine.
> I think the arguments given on this list for why we need this interface > were mainly academic
Hrm, so my argument about Object::getClass() was academic? I actually never finished my degree:)
> and an attempt of people familiar with Java to copy > the hierarchy.
A lot of people have base classes and let all of their other classes extend them. I don't think this is specifically related to Java.
I wouldn't say "a lot". In most code I have seen this doesn't happen. Yes, I have seen very small amount of places where it does, and in that case, they didn't have exceptions and I don't think that in all situations having the exceptions inherit that class is important.
Of course, I know how to work around this - by duplicating code into subclasses of exceptions, by simply having a global function or writing an extension which gets rid of the exception class after Engine startup, but wouldn't these solutions be rather "unclean" and wasn't your argument for this that it is a "clean" solution?
Look at it the other way around: Would anybody be investing such an amount of time into arguing (which, ATM, I am) *if* we had the interface solution?
> The actual times you will need such an interface is quite > rare and I don't think it's worth the complexity for the one in a million > purist guy (i.e. people who want all their classes to inherit from a > CObject including exceptions).
Again, I don't see any complexity arising from this: The average user would simply use "catch (IException $e)" instead of "catch (Exception $e)" and have what he/she wants: All exceptions are being caught.
The "purist guy" (me, in this case) would use the same semantics *and* be able to have all of the purist and academic stuff he wants:)
But that's exactly it. PHP is not for the purist and academic guy like you. We don't try and please people like you :)
We want to keep PHP accessible and easy to use for the masses and adding an additional layer complicates things for the end user. You are more advanced than the average PHP developer as you are writing C code for the PHP core :)
Look, I'm not very strongly against this interface but you (and some others here) have to understand that you are not the average PHP user and PHP has never been targeted at the academy. There are plenty of languages to take that spot such as LISP, ML, Java, Prolog, Smalltalk and so on... Sometimes being not quite 100% pure makes the language easier to use and to understand.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
