Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuSyBun+vr=OXBzNEpoHHvtDthJnteERHknmdGRVGZk0tg@mail.gmail.com>
References: <CA+kxMuTh4haa=wF8h_gMp+cMocK3sG8sxwZnG=NHCORKi41TYQ@mail.gmail.com>
	<CA+9eiLvH_1itW9fVsv_FoX+MXuWz18XLQvELEimuaoPgAAGBVA@mail.gmail.com>
	<CA+kxMuQPoDDv8CDmCJhiiPJ+rRs0nYFQxy=ZPVWfP-YqFb0Nuw@mail.gmail.com>
	<CA+9eiLsd_i4UNCBGOM=ZUM-MN+CS26cSd2zTD-dHJ4iAm3F=GQ@mail.gmail.com>
	<CAF+90c_u=zMAnGijUAw8aFa5XB=-WK+4Rn1KEa4LMunxVQ3M8Q@mail.gmail.com>
	<CA+9eiLvTQ-4Dc5wcXCYouE0fE3Ls8CmZOSWB9xGXd5XHkpNOrg@mail.gmail.com>
	<CA+kxMuSyBun+vr=OXBzNEpoHHvtDthJnteERHknmdGRVGZk0tg@mail.gmail.com>
Date: Fri, 3 Apr 2015 17:31:12 +0200
Message-ID: <CAF+90c_B-m6Jv3A4W84vZ7B33j==X2q0SY5BVomRKu+tXondyQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Dmitry Stogov <dmitry@zend.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2b3486a4b3e0512d3a37a
Subject: Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c2b3486a4b3e0512d3a37a
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 1, 2015 at 3:31 AM, Dan Ackroyd <danack@basereality.com> wrote:

> Hi Dmitry,
>
> Your approach is definitely a better one, and I have no objection to
> it whatsoever.
>
> Sorry, I was too busy to look deeply at each class but I can't see any
> problems.
>
> Nikita Popov wrote:
> > does that mean that the same code using strict_types=1 mode will start
> > throwing TypeException instead of whatever exception type is passed
> > to replace_error_handling?
>
> That's going to affect everything isn't it - not just this RFC?
>
> However I think that is the correct behaviour. It more closely
> resembles the behaviour that will be seen in userland code, and is
> more 'semantically' meaningful i.e. it allows people to tell the cases
> between the two types of errors apart.
>
> It probably bears more thinking about though.
>
> cheers
> Dan
>
>
>
> $formatInfoList = [
>     ["en_US", "{0,number,integer} monkeys on {1,number,integer} trees
> make {2,number} monkeys per tree"],
>     ["en_US", '{this was made intentionally incorrect}'], //valid type
> but wrong value
>     ["en_US", new StdClass] //wrong type
> ]
>
>
> foreach ($formatInfoList as $formatInfo) {
>     list($locale, $pattern) = formatInfo;
>     try {
>         $mf = new MessageFormatter($locale, $pattern);
>         echo $mf->format(array(4560, 123, 4560/123));
>     }
>     catch(IntlException $ie) {
>          // A strict type-est person would not want this to catch the case
> where
>          // the wrong type has been passed, as it's not an exception
> related to Intl
>          // it's an exception related to the type being wrong.
>     }
> }
>

PR for throwing TypeException (independently of strict mode) for zpp
failures in constructors is here: https://github.com/php/php-src/pull/1215
Will apply it if nobody sees a problem with it.

Nikita

--001a11c2b3486a4b3e0512d3a37a--