Re: [RFC][VOTE] Constructor behaviour of internal classes

I don' t see any problems. Thanks. Dmitry. On Fri, Apr 3, 2015 at 6:31 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > 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 >