On Wed, Apr 1, 2015 at 4:31 AM, Dan Ackroyd <dan...@basereality.com> wrote:
> Hi Dmitry,
>
> Your approach is definitely a better one, and I have no objection to
> it whatsoever.
>
Your patch was quite good. You just didn't know what this NULL return
required a hack in the PHP core :)
>
> Sorry, I was too busy to look deeply at each class but I can't see any
> problems.
>
Great.
Nikita, do you like me to commit this PR or will you take care about it?
Thanks. Dmitry.
>
> 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.
> }
> }
>
