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 <simonsimc...@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 <johncrens...@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.cr...@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 <johncrens...@priacta.com
>> <mailto:johncrens...@priacta.com>> wrote:
>> > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vch...@developersdesk.com
>> <mailto:vch...@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.
>>
>>
>
