Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84218
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54F49882.9090901@gmail.com>
Date: Tue, 3 Mar 2015 08:27:29 +0100
Cc: Dan Ackroyd <danack@basereality.com>,
 "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
From: mike@php.net (Michael Wallner)


>> 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.
>=20
> 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.
>=20

None of them cause a fatal error, because it behaves contrary to =
established=20
standards.

>> Quoting php.net/manual:
>>=20
>> 	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*.
>=20
> Manual can be fixed.

Everything can be =E2=80=9Cfixed=E2=80=9D, but what=E2=80=99s the right =
thing to fix? Documentation=20
valid for a decade that covers 98% of use cases, which will cause =
everyone=20
to revisit any instance of `new` with internal constructors or rather =
fix those=20
internal classes misbehaving.=20

>=20
>> 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?
>=20
> 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 =
finds that=20
undocumented and unexpected behaviour useful?
To me this is as useful as an internal class crashing because it =
doesn=E2=80=99t=20
check if it was instantiated correctly.

Regards,
Mike