Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84155
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54F4264B.4030309@lsces.co.uk>
Date: Mon, 02 Mar 2015 08:58:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: 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: lester@lsces.co.uk (Lester Caine)

On 02/03/15 07:57, Michael Wallner wrote:
> I'm not sure I can understand your crusade against this topic.
> 
> 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.
> 
> 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*.
> 
> Emphasis mine.

And did you actually read them?
This is something that came in with 'constructors' and only when an
exception is *required* is one raised.
It is only that particular 'improvement' to coding style that brought in
the need for an exception, but something which seems to have been missed
is what should happen if the object is created but in a state that it
can't actually be used?
There are many cases where a null handle is still a more practical
return and that element of PHP seems to have been lost? That the  manual
does not reflect the whole of the language is a well established fact :(

> 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
> explicitely ask for that behavior?

One might ask why C++ programmers see an advantage in that particular
action I have my own style of working which originated in Algol and
progressed to C++ prior to PHP so for me there is nothing wrong except
perhaps the increasing pressure to create objects where a simple data
value is all that is needed. PDORow is a holder for a set of data ... it
only needs to be called when one has a result set to view and once all
the results are viewed 'null' is it's natural state. Calling it without
a result set is an 'invalid number of arguments' but a resulting null
handle is still the correct state for the work flow and this is the case
in many of the empty objects which PHP naturally encounters? This is
just the same debate as 'empty string = false'!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk