Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84212
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
Message-ID: <54F49882.9090901@gmail.com>
Date: Mon, 02 Mar 2015 09:06:10 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Michael Wallner <mike@php.net>, Dan Ackroyd <danack@basereality.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com> <54F38D29.9080007@gmail.com> <54F417E1.8010703@php.net>
In-Reply-To: <54F417E1.8010703@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal
 classes
From: smalyshev@gmail.com (Stanislav Malyshev)

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