Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80839
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALJZF3iiYQ=+aCvfuE5gWyZe+vfgBCepH1sxa27zB1NOVgqyTQ@mail.gmail.com>
References: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
	<54BC9909.6090100@gmail.com>
	<CAH-PCH7_wEf52aaH8ytGpmmOdXDgs1+8+fjwGLgf35yF2fSu_g@mail.gmail.com>
	<CALJZF3iiYQ=+aCvfuE5gWyZe+vfgBCepH1sxa27zB1NOVgqyTQ@mail.gmail.com>
Date: Mon, 19 Jan 2015 18:36:56 +0100
Message-ID: <CAH-PCH655pm75pQ+rfgS8Fn5Udc+R2ZR89vLq6VFOt_JqRmKHw@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Dan Ackroyd <danack@basereality.com>, PHP Internals <internals@lists.php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bd9058ed2fbc3050d04c4b1
Subject: Re: [PHP-DEV] Class constructor behaviour
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bd9058ed2fbc3050d04c4b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 19, 2015 at 6:04 PM, Michael Wallner <mike@php.net> wrote:

>
> On 19 Jan 2015 12:30, "Ferenc Kovacs" <tyra3l@gmail.com> wrote:
> >
> > On Mon, Jan 19, 2015 at 6:41 AM, Stanislav Malyshev <smalyshev@gmail.co=
m
> >
> > wrote:
> >
> > > 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 th=
an
> > > handling exception (and faster too, probably). Many functions that tr=
y
> > > 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 wh=
y
> > > 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=3D119263748000001&r=3D1&w=3D2 )=
 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 constructo=
r
> > > > 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.....a=
nd
> > > > then just give a warning when they are not acceptable. e.g.
> > >
> > > These should be fixed to either return null or throw exception, but t=
he
> > > behavior should be unified for everybody.
> > >
> > > > Again, this should be fixed by changing the constructors to throw a=
n
> > > > 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 emi=
t
> > > > 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 al=
l
> > > together.
> > >
> > > >
> > > > <?php
> > > > $foo =3D 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 eve=
ry
> > > class that gets incompatible parameters. And probably user-space func=
s
> > > too since there's no reason for them to behave differently. I actuall=
y
> > > wouldn't mind that, but this is yet bigger can of worms as it require=
s
> > > refactoring a lot of assumptions on how parameters are parsed.
> > >
> > > > i) Can anyone see a big hurdle in fixing these behaviours, other th=
an
> > > > 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 tha=
t
> > > > 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
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> > Hi,
> >
> > AFAIK (based on
> > http://www.mail-archive.com/internals@lists.php.net/msg43237.html and
> other
> > discussions) errors in constructors should throw exceptions (even for
> > classes in core).
> >
>
> Definitely my take on this, too. If userland constructors cannot return
> anything than an instance of the class, why should internal?
>
yep, ofc. this means that there are a couple of class method->function
aliases which have to be changed/refactored, so calling the procedural
counterpart won't throw exceptions, but thats shouldn't be a problem.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bd9058ed2fbc3050d04c4b1--