Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58327 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77064 invoked from network); 29 Feb 2012 09:12:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 09:12:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=simonsimcity@googlemail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=simonsimcity@googlemail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender) X-PHP-List-Original-Sender: simonsimcity@googlemail.com X-Host-Fingerprint: 209.85.214.170 mail-tul01m020-f170.google.com Received: from [209.85.214.170] ([209.85.214.170:63910] helo=mail-tul01m020-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E2/CC-36673-81CED4F4 for ; Wed, 29 Feb 2012 04:12:57 -0500 Received: by obbwd1 with SMTP id wd1so1439566obb.29 for ; Wed, 29 Feb 2012 01:12:54 -0800 (PST) Received-SPF: pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.124.41 as permitted sender) client-ip=10.182.124.41; Authentication-Results: mr.google.com; spf=pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.124.41 as permitted sender) smtp.mail=simonsimcity@googlemail.com; dkim=pass header.i=simonsimcity@googlemail.com Received: from mr.google.com ([10.182.124.41]) by 10.182.124.41 with SMTP id mf9mr8188686obb.65.1330506774442 (num_hops = 1); Wed, 29 Feb 2012 01:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I+bnJgml95ZvXKJHvC5wa3CxOrcC7/zlHxairDHDg+c=; b=sgNNWnZSWrxu5vSt9dfgs04bp7LwMLz1tw9avD13yG1xDlhV3eNzgO0pxW6OLSGGqv ziltq/5vh0GYi82MDGTA6ME4Ka0eQ0/JEiwziPEU7dD8uXkUB7xyNBeb7LVSDHDLHBAu CFJuOh/5WF1P3A2lTFcFIZhMIll9OfdIcQvIQ= MIME-Version: 1.0 Received: by 10.182.124.41 with SMTP id mf9mr7200055obb.65.1330506774365; Wed, 29 Feb 2012 01:12:54 -0800 (PST) Received: by 10.60.7.229 with HTTP; Wed, 29 Feb 2012 01:12:54 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> Date: Wed, 29 Feb 2012 10:12:54 +0100 Message-ID: To: John Crenshaw Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=f46d0444eebba8444e04ba16bf3b Subject: Re: [PHP-DEV] Scalar type hinting From: simonsimcity@googlemail.com (Simon Schick) --f46d0444eebba8444e04ba16bf3b Content-Type: text/plain; charset=UTF-8 Hi, We could even combine this with the following RFC: https://wiki.php.net/rfc/object_cast_magic If an integer is required and you pass an object, it first checks if this object is castable to integer ;) Bye Simon 2012/2/29 Simon Schick > Hi, John > > I personally do not care about weak or strong variables at all ... I only > want what Arvids suggested last time: > > > > test(1, 2); // 2; > > test("1", 2); // 2 > > test("1aaa", 2); // E_NOTICE or E_TYPE and result 2 > > test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type > hint now. > > > > It's really what the most people want. Simple, easy to pick up (object > > and array already have this) and is just optional. > > I count myself as a part of *most people* in this statement ;) > I'm also quite fine with the current type-hints as you'd anyways get an > error if you try something like this: > > function foo(SimpleClass $a) { > $a->getName(); > } > > foo("Test"); > > If you now get *method called from an non-object* or a message that you > have passed a value that's not compatible with *SimpleClass* ... > > I'd like to split this discussion in parts: > > - just type-hint in functions (as we have it with classes and arrays) > or bind a variable to a strict type? > - should it then also be possible bind variables to a specific > class or interface? > - should we go for weak or strong types? > - the type-hint is also weak in one way because it accepts all > that's compatible with the given type. > > Bye > Simon > > > 2012/2/29 John Crenshaw > >> I would personally be inclined towards something simpler like E_NOTICE or >> E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we >> should be consistent, and the consistency argument may make the difference. >> >> There may be a strong case for changing the error level on all type hints >> to something simpler (or new, like E_TYPE), but I think that might be >> better to tackle that in a separate discussion. >> >> John Crenshaw >> Priacta, Inc. >> >> From: Kris Craig [mailto:kris.craig@gmail.com] >> Sent: Tuesday, February 28, 2012 8:40 PM >> To: John Crenshaw >> Cc: Rick WIdmer; internals@lists.php.net >> Subject: Re: [PHP-DEV] Scalar type hinting >> >> I wouldn't mind that, though I'm concerned that it may not be sellable >> because some people on here have expressed a strong opinion that this >> shouldn't throw anything more than a notice or a warning at most, something >> that I and others strongly disagree with. The logical approach, to me at >> least, is to follow the example of include() and require(); i.e. they're >> both identical except that one throws a scary error while the other one is >> just a warning. >> >> I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may >> alienate too many people for us to be able to get this through. Though >> it's possible I might be overestimating that factor. >> >> --Kris >> >> On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw > > wrote: >> > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer > >wrote: >> > >> > > On 2/28/2012 2:58 PM, Kris Craig wrote: >> > > >> > > strong int $a = "1"; // Converts to 1. May or may not throw an error >> > > (I'm >> > >> still on the fence). >> > >> >> > > >> > > It this is an error, it is no longer PHP. >> > > >> > >> > @Rick Though I'm not sure I'd agree with the overly broad "it is no >> longer PHP" hyperbole, I think the basic point that it would be a >> significant departure from the current model has merit. So ok, you've >> convinced me. >> That example should not throw any errors. I'm officially no longer on >> the fence with that. =) >> > >> > --Kris >> OK, if we're all on the same page there, I think this means that there is >> no significant difference between the "strong int" and "weak int" in your >> proposal (the only remaining difference being the level of error raised >> when it cannot be converted, which IMO is not substantial enough to deserve >> a keyword.) I'd prefer to just pick one error level to use >> (E_RECOVERABLE_ERROR would be the most consistent) and keep everything >> simple. >> >> John Crenshaw >> Priacta, Inc. >> >> > --f46d0444eebba8444e04ba16bf3b--