Re: Scalar type hinting

I agree with the notion of typing in function arguments, though I'm not a fan of this particular approach. Specifically, I don't like the idea of "1aaa" throwing one kind of error (E_NOTICE) and array($whatever) throwing another kind of error. They should both throw the same error because they're both incompatible types; i.e. "1" == 1 but "1aaa" != 1. I don't like the idea of saying that one incompatible type is "worse" than another. I just don't see any value in that and it ultimately just makes things more confusing and complicated than they need to be for the end-user. Instead, they should both throw the same kind of error. Whether it's just E_RECOVERABLE_ERROR or we give the developer a choice by having strong/weak, I'm fine either way (though I think the second approach adds more flexibility without any practical drawbacks). And again, let's avoid using phrases like "most people". I'll let Wikipedia elaborate on why: http://en.wikipedia.org/wiki/Weasel_word --Kris On Wed, Feb 29, 2012 at 2:26 AM, Simon Schick <simonsimcity@googlemail.com>wrote: > Hi, Arvids > > I did not meant to putt all in one big RFC but more to think about the > connection between these two while developing. > > Bye > Simon > > 2012/2/29 Arvids Godjuks <arvids.godjuks@gmail.com> > > > 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 <simonsimcity@googlemail.com>: > > > 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 <simonsimcity@googlemail.com> > > > > > >> 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 <johncrenshaw@priacta.com> > > >> > > >>> 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 < > > johncrenshaw@priacta.com > > >>> <mailto:johncrenshaw@priacta.com>> > > >>> wrote: > > >>> > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer < > > vchkpw@developersdesk.com > > >>> <�Z����$ж6 > > >>> ��mailto:vchkpw@developersdesk.com>>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. > > >>> > > >>> > > >> > > >