Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84268
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <D1E6B8D5-EDFC-460C-A383-BF59FD7E2201@php.net>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com>
 <54F38D29.9080007@gmail.com> <54F417E1.8010703@php.net> <54F49882.9090901@gmail.com>
 <D1E6B8D5-EDFC-460C-A383-BF59FD7E2201@php.net>
Date: Wed, 4 Mar 2015 08:55:33 +0900
Message-ID: <CAGa2bXaNDif1ZaEDAO7ssgPLq-wYe8yER9+OhpqPpqVnXzO62g@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Dan Ackroyd <danack@basereality.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114596a8656d7205106b1418
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a114596a8656d7205106b1418
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Tue, Mar 3, 2015 at 4:27 PM, Michael Wallner <mike@php.net> wrote:

> >
> >> 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=E2=80=99s okay, but do you think the majority of PHP developers find=
s that
> undocumented and unexpected behaviour useful?
> To me this is as useful as an internal class crashing because it doesn=E2=
=80=99t
> check if it was instantiated correctly.


Let's be consistent. If error happened during object instantiation, raise
exceptions.

Returning NULL for this case would be OK. We may be better to be consistent
because exceptions can be ignored.

There are 2 possibilities, return NULL or FALSE
Always return NULL or FALSE for errors?

Many procedural functions return FALSE for error. Most notable exceptions
are argument count errors that return NULL. It may be better cleanup these
inconsistent behaviors also.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a114596a8656d7205106b1418--