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

>> 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. > None of them cause a fatal error, because it behaves contrary to established standards. >> 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. Everything can be “fixed”, but what’s the right thing to fix? Documentation valid for a decade that covers 98% of use cases, which will cause everyone to revisit any instance of new with internal constructors or rather fix those internal classes misbehaving. > >> 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. That’s okay, but do you think the majority of PHP developers finds that undocumented and unexpected behaviour useful? To me this is as useful as an internal class crashing because it doesn’t check if it was instantiated correctly. Regards, Mike