committed into master.
Dan, please update the RFC accordingly.
Thanks. Dmitry.
On Wed, Apr 1, 2015 at 11:14 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> 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.
>> }
>> }
>>
>
>
