Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58328 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80053 invoked from network); 29 Feb 2012 09:28:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 09:28:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=arvids.godjuks@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=arvids.godjuks@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender) X-PHP-List-Original-Sender: arvids.godjuks@gmail.com X-Host-Fingerprint: 209.85.212.170 mail-wi0-f170.google.com Received: from [209.85.212.170] ([209.85.212.170:49546] helo=mail-wi0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/6D-36673-AAFED4F4 for ; Wed, 29 Feb 2012 04:28:11 -0500 Received: by wibhj13 with SMTP id hj13so531038wib.29 for ; Wed, 29 Feb 2012 01:28:07 -0800 (PST) Received-SPF: pass (google.com: domain of arvids.godjuks@gmail.com designates 10.180.93.4 as permitted sender) client-ip=10.180.93.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of arvids.godjuks@gmail.com designates 10.180.93.4 as permitted sender) smtp.mail=arvids.godjuks@gmail.com; dkim=pass header.i=arvids.godjuks@gmail.com Received: from mr.google.com ([10.180.93.4]) by 10.180.93.4 with SMTP id cq4mr46346395wib.21.1330507687327 (num_hops = 1); Wed, 29 Feb 2012 01:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DTwd3JG4kJzUde8PeIPEtARRhC9MkWTS+nZGAfOPJ7Y=; b=PCkjmn0Rnr4YlG6rVhoXklVppmyvjoBeKxPBNfaj8g3fudCZQh+50HuAdz2t/HzgqU Nif4hASlNt1qiZBIH/SrY4CpmSA5gEPzem4k9dh53qrIx8MO2M4EzDn30ewyTGS7Pq5p 2TBLX1edYkvD6sqWNvO14bMeb9coZffWOU5X0= Received: by 10.180.93.4 with SMTP id cq4mr36827512wib.21.1330507687195; Wed, 29 Feb 2012 01:28:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.117.1 with HTTP; Wed, 29 Feb 2012 01:27:47 -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 11:27:47 +0200 Message-ID: To: Simon Schick Cc: John Crenshaw , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Scalar type hinting From: arvids.godjuks@gmail.com (Arvids Godjuks) Combining different things into one big RFC is not a good idea. It's hard to develop and test the work it it's in one big chunk. Decomposition makes it much easier. Type hinting has to have it's own RFC. Besides - someone can be willing to do type hinting patch and don't want to do the object_cast_magic one. And thanks for the support :) 2012/2/29 Simon Schick : > 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 onl= y >> 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) { >> =C2=A0 $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: >> >> =C2=A0 =C2=A0- just type-hint in functions (as we have it with classes a= nd arrays) >> =C2=A0 =C2=A0or bind a variable to a strict type? >> =C2=A0 =C2=A0 =C2=A0 - should it then also be possible bind variables to= a specific >> =C2=A0 =C2=A0 =C2=A0 class or interface? >> =C2=A0 =C2=A0- should we go for weak or strong types? >> =C2=A0 =C2=A0 =C2=A0 - the type-hint is also weak in one way because it = accepts all >> =C2=A0 =C2=A0 =C2=A0 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 thin= k we >>> should be consistent, and the consistency argument may make the differe= nce. >>> >>> There may be a strong case for changing the error level on all type hin= ts >>> 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, somet= hing >>> that I and others strongly disagree with. =C2=A0The logical approach, t= o me at >>> least, is to follow the example of include() and require(); i.e. they'r= e >>> 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. =C2=A0T= hough >>> 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: >>> > > >>> > > =C2=A0strong int $a =3D "1"; // Converts to 1. =C2=A0May 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. =C2=A0So ok, yo= u've >>> convinced me. >>> That example should not throw any errors. =C2=A0I'm officially no longe= r on >>> the fence with that. =C2=A0=3D) >>> > >>> > --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 yo= ur >>> proposal (the only remaining difference being the level of error raised >>> when it cannot be converted, which IMO is not substantial enough to des= erve >>> 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. >>> >>> >>