Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80767
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
Message-ID: <54BC9909.6090100@gmail.com>
Date: Sun, 18 Jan 2015 21:41:29 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Dan Ackroyd <danack@basereality.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
In-Reply-To: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Class constructor behaviour
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> This is pretty horrible and should be fixed by making sure that

I don't see why it's so horrible. In fact, handling null is easier than
handling exception (and faster too, probably). Many functions that try
to create objects return null or false when unable to. Of course, we
could change it by introducing exceptions to core, but I don't see why
do it peacemeal then.

> constructors either return an object or throw an exception.
> Additionally the exception policy for core (that was previously
> discussed here: http://marc.info/?t=119263748000001&r=1&w=2 ) should
> be updated so that any constructor returning NULL is considered a bug,
> no matter what the ini settings are. To be clear, procedural code
> should behave as before, with users expected to check for errors.
> This would be a BC break for people who are handling the constructor
> returning null currently, as they would need to wrap that code with an
> try/catch block.

That means the same failure of collator construction now needs to be
handled in two different ways.

> Constructors give warning, but are then in an unusable state
> ------------------------------------------------------------
> Several constructors check the parameters that they are given.....and
> then just give a warning when they are not acceptable. e.g.

These should be fixed to either return null or throw exception, but the
behavior should be unified for everybody.

> Again, this should be fixed by changing the constructors to throw an
> exception if the input parameters are not acceptable.

The next question would be - if the ctors throw an exceptions, why
factory methods shouldn't? They are doing the same work essentially.

> Constructor gives error
> -----------------------
> 
> Some constructors check the parameters they are given, and then emit
> either a 'Catchable fatal error' error or other error e.g.

This is even bigger can of worms. If we wrote PHP today from scratch,
catchable fatal errors would be exceptions. But they are not, so we need
to deal with it - by either leaving them as is, or converting them all
together.

> 
> <?php
> $foo = new IntlGregorianCalendar(new StdClass);
> //Output: Catchable fatal error: Object of class stdClass could not be
> converted to string in..

This is not property of the ctor, it's property of parameter handling.
I.e. if you do it for IntlGregorianCalendar, you should do it for every
class that gets incompatible parameters. And probably user-space funcs
too since there's no reason for them to behave differently. I actually
wouldn't mind that, but this is yet bigger can of worms as it requires
refactoring a lot of assumptions on how parameters are parsed.

> i) Can anyone see a big hurdle in fixing these behaviours, other than
> it being a BC break for people who are currently relying on these
> behaviours ?

Yes. The first hurdle is to understand which of these behaviors need
fixing, and how, which you seem to dismiss as obvious but it's really
not. The second is to do it in consistent manner so it doesn't again
come out as part of the functions do one thing, another part another,
and third part something else different.

> ii) Are there any other bad behaviours that people are aware of that
> ought to be fixed at a major version?

I think we have enough for now to discuss here, so if we want do discuss
other behaviors better to open separate thread.

-- 
Stas Malyshev
smalyshev@gmail.com