Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58346 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79388 invoked from network); 29 Feb 2012 20:18:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 20:18:29 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.170 mail-we0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:38954] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/07-46815-3188E4F4 for ; Wed, 29 Feb 2012 15:18:28 -0500 Received: by werh12 with SMTP id h12so2837952wer.29 for ; Wed, 29 Feb 2012 12:18:24 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.80.40 as permitted sender) client-ip=10.180.80.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.180.80.40 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.180.80.40]) by 10.180.80.40 with SMTP id o8mr3995636wix.10.1330546704586 (num_hops = 1); Wed, 29 Feb 2012 12:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vhtxusGpkNVgl2Dm1ToE9KYT1hUW3+w4LGSmoW5cAOY=; b=ON2WtUHBa+JOnth9QusKbEfO6i+Sp2amGeXtDaIJGpnKlcXD8W5vCAFNt27lsvbv8L M0T7yW4TWru4lY52qjAIjbZ1zH1+AeYSANrY7Or1ZVHCYNLvQM/PeUUUmj+CSyCGA48Z 9bfM4m7ltKG/VFNQ+sVk5egbaLaqJ0cMmb57U= MIME-Version: 1.0 Received: by 10.180.80.40 with SMTP id o8mr3213885wix.10.1330546704473; Wed, 29 Feb 2012 12:18:24 -0800 (PST) Received: by 10.223.75.146 with HTTP; Wed, 29 Feb 2012 12:18:24 -0800 (PST) In-Reply-To: References: <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> Date: Wed, 29 Feb 2012 12:18:24 -0800 Message-ID: To: Simon Schick Cc: Richard Lynch , internals@lists.php.net Content-Type: multipart/alternative; boundary=f46d04428b8ead5f8b04ba200bb6 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --f46d04428b8ead5f8b04ba200bb6 Content-Type: text/plain; charset=ISO-8859-1 @Simon Agreed. That's pretty much what I'm thinking it should look like. With booleans, I think you have a good point. If 1 or 0 is passed to a bool, I'd say that should be fine without an error. If you were to pass a 2, though (you insolent bastard!), then it would throw the error. I think we're getting pretty close to having enough to write an RFC for this. I'll go ahead and create one after a little more discussion goes around. --Kris On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick wrote: > Hi, Kris > > I don't think we have to care about scripts that are written right now if > we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because > this feature is completely new. But I like the idea to have all type-hint > failures ending up the same way. > > I personally would keep the error-messages for classes and arrays as they > are right now and do the same error in case the given value is not > compatible to the expected type. > Not compatible means that data gets lost after converting the data into > the other data-type. > > Lets have an example: > > function foo(integer $i) { > // do something > } > > foo(true); // Even if Boolean is a lower type than int, it can be easily > casted to an int. It's equivalent to 1. > foo("1"); // wont throw an error because the transformation into an > integer is loose-less > foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an > integer is required here. > foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform > "horse" into a float, it's 1 and that's not equal to the string anymore. > > I personally would treat float - int miss matches the same way as all > other stuff, because it cannot be converted loose-less. > > And if the Object-cast-stuff comes through, we have to think about this in > addition: > https://wiki.php.net/rfc/object_cast_magic > > class MyInteger { > public function __castTo(string $type) { > if ($type === "integer") > return 5; > } > } > > function foo(integer $i) { > // do something > } > > foo(new MyInteger()); // Even if this is an object - it's cast-able to an > integer and therefore should be valid > > But this is just in case the RFC gets through ;) We don't have to think > that much about it now - just keep it in mind. > > Bye > Simon > > > 2012/2/29 Kris Craig > >> Now that I think of it, this would probably be a good argument for >> differentiating between strong and weak. Looking back to my previous >> comment, it probably would be best to have it behave the same regardless >> of >> what the incompatible type is. But in the case where a float might sneak >> its way into an int, the developer might decide that going with a weak >> type >> would make it more flexible (though if it was me, I'd just do a round or >> leave it a mixed type lol). >> >> --Kris >> >> >> On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig >> wrote: >> >> > @Richard I think you made a very good point. Should we treat a float => >> > int mismatch the same as we would a string => int mismatch, or should >> the >> > former fail more gracefully? I can see good arguments for both. >> > >> > --Kris >> > >> > >> > >> > On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch wrote: >> > >> >> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: >> >> >> >> Some cases I would find interesting to be explained: >> >> >> >> (using 'streak' for strong and/or weak, feel free to separate the two) >> >> >> >> streak int $i = 123.456; //Common idiom for floor() >> >> streak int $i = "123.456"; //In contrast to previous >> >> streak int $i = "1 "; //value="1 " is ridiculously common HTML >> >> >> >> It's all well and good to say that any loss of data is "bad" and to >> >> raise some E_* for it, but there are some idioms so common that feel >> >> "wrong" as I consider them... >> >> >> >> If everyone "for" the new type hinting/forcing can reach consensus on >> >> these sorts of cases, it would help clarify any RFCs a bit, I think >> >> >> >> wrt E_RECOVERABLE_ERROR vs E_WARNING >> >> >> >> If current type hinting raises E_RECOVERABLE_ERROR, I have no >> >> objection to following that lead, with the explicit caveat that a >> >> change to the existing type-hinting to E_WARNING, as unlikely as that >> >> seems, would pull the new "streak" with it. >> >> >> >> I don't even object to using E_ERROR for the "strong" variant, if that >> >> passes review, really, since "strong" is, errr, strong. :-) >> >> >> >> Anybody who doesn't like the E_* can re-define them in a custom error >> >> handler anyway, though allowing PHP to continue after E_ERROR is like >> >> playing russian roulette... >> >> >> >> -- >> >> brain cancer update: >> >> http://richardlynch.blogspot.com/search/label/brain%20tumor >> >> Donate: >> >> >> >> >> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE >> >> >> >> >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> > >> > > --f46d04428b8ead5f8b04ba200bb6--