Re: [RFC][DISCUSSION] Constructor behaviour of internal classes

Hi! > I'm not sure I can understand your crusade against this topic. I would start with trying to address my actual arguments, as opposed to dismissing it as a "crusade". I've described my arguments for it in my previous emails, is there something unclear there? I'd be happy to explain any point further. > Consistency with userland is beneficial, because the majority of PHP > developers probably do not expect new to yield anything than a > concrete instance or an exception. Of course, consistency with userland is beneficial. However, in userland we do not have many things that we have in internals - like operator overloading, function aliasing, etc. - because some of the functionality we consider risky and as such better to be left to internals/extensions. This is one more example. > Quoting php.net/manual: > > To create an instance of a class, the new keyword must be used. An > object will *always* be created *unless* the object has a constructor > defined that *throws an exception on error*. Manual can be fixed. > Do you know of any other case where a new operator in an object > oriented context can return NULL, except C++ where you have to > explicitly ask for that behavior? I can't say I am familiar with every OO language's implementation details, so I don't know. But I don't see why, if we think it's useful, we can not do it - especially given our factory methods/functions already do it. I think it's useful. -- Stas Malyshev smalyshev@gmail.com