Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85618 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19945 invoked from network); 1 Apr 2015 01:32:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Apr 2015 01:32:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=danack@basereality.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=danack@basereality.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.217.169 cause and error) X-PHP-List-Original-Sender: danack@basereality.com X-Host-Fingerprint: 209.85.217.169 mail-lb0-f169.google.com Received: from [209.85.217.169] ([209.85.217.169:34367] helo=mail-lb0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 65/A5-19757-D8A4B155 for ; Tue, 31 Mar 2015 20:31:59 -0500 Received: by lboc7 with SMTP id c7so25384913lbo.1 for ; Tue, 31 Mar 2015 18:31:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z81A1TgvHVPYhku8PjKF/GcOTutLnU1fli7r08SjrS0=; b=fEwHN+IbxBwItsepWLXopgPzFIKbmAvSR5UHq2sHwyVIIV1t4/Xs3hO/UULRt/2W38 OnZoa/5e9TMaHd3Z0cEoS1/i4+pA5r2lKUVsVDNu8gT69yWwe85jAtJhor8+szYa+Wo1 8f4lFO6lkP3xSxGtRZhVQuCkzSmcDTlz8qU2yXD74ooitFEe8qebweywE+2kbvNWzxtB jgF2zDDOEUamyknudNjDp//+/439xJ7Aa7HARuYm6z0EyhueJJ3VKk1g6LgCa6uI4xQP 43r6/rROdxVei/hb3IoPRdKj0MRMubXhehaIXrYd6e+E7tAzJYE5X1GjaIxpEupmZNf5 TZkg== X-Gm-Message-State: ALoCoQmLn/UX9Va/m63DOmHiNlk/aLs1b72U7TrA8YtHi3g0AYB8UN8ncJAXkTQ7kZ16ZmlT5a/C MIME-Version: 1.0 X-Received: by 10.152.6.34 with SMTP id x2mr6614168lax.47.1427851914670; Tue, 31 Mar 2015 18:31:54 -0700 (PDT) Received: by 10.25.87.202 with HTTP; Tue, 31 Mar 2015 18:31:54 -0700 (PDT) X-Originating-IP: [78.144.121.114] In-Reply-To: References: Date: Wed, 1 Apr 2015 01:31:54 +0000 Message-ID: To: Dmitry Stogov Cc: Nikita Popov , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes From: danack@basereality.com (Dan Ackroyd) 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. } }