@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
<simonsimc...@googlemail.com>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 <kris.cr...@gmail.com>
>
>> 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 <kris.cr...@gmail.com>
>> 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 <c...@l-i-e.com> 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
>> >>
>> >>
>> >
>>
>
>
