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
> >>
> >>
> >
>
