Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error("Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,", E_RECOVERABLE_ERROR);
}
The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.
Bye
Simon
2012/3/1 John Crenshaw <johncrens...@priacta.com>
> > > > From: Richard Lynch [mailto:c...@l-i-e.com]
> > > > On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > > > > I'm beginning to think that the type hinting question is too
> closely
> > > > > related to the dirty secrets of type juggling to resolve them
> > > > > separately. You may have to either discard consistency, or else fix
> > > > > the problem of silent bizarre conversions at the same time
> ('foo'==0,
> > > > > '123abc'=123). Fixing the conversions is a BC break though.
> > > >
> > > > [short version]
> > > > One man's "fixing" is another man's "feature" :-)
> > > >
> > > > Old hands can now hit delete while I wax philosophical.
> > >
> > > The operative word was "silent". The actual behavior is fine, but the
> > > silence is unexpected. For example, PHP happily accepts substr('foo',
> > > 'bar') with no complaint at all. From a purely philosophical
> perspective I
> > > think almost everyone would expect *at least* a strict notice.
> > >
> > > On a practical level, we have a major barrier and we'll have to decide
> how
> > > to handle it. As I see it we could do one of the following:
> > > 1. Discard consistency (!!)
> > > 2. Try to convince people to make these bizarre conversions not silent
> (BC
> > > break)
> > > 3. Try to find a creative solution to be consistent without changing
> > > anything about the conversion behavior. (I'm not seeing a way to do
> this
> > > one, unless we redefine "consistent".)
> > >
> > > John Crenshaw
> > > Priacta, Inc.
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> > On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick <
> simonsimc...@googlemail.com> wrote:
> > Hi, John
> >
> > Just to add an idea to yours ..
> >
> > Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
> > or E_WARNING if we f.e. try to give a string to a method that just allows
> > integer for this argument?
> > No break at all, just a E_NOTICE or E_WARNING as the script can succeed
> > anyways.
> > Perhaps I missed something, but since 5.3, the new parameter parsing API
> > throws a Warning when types are not strictly honored.
> > This has been a major feature in favor of "cleaner" programming.
> >
> > Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
> > function returns null.
> >
> > Julien.P
> >
> > Bye
> > Simon
> >
>
> Ah, didn't notice the *new* behavior. That simplifies things substantially.
>
> I also had another realization today, which is that there's already strong
> precedent for treating parameter hints more aggressively than a type cast.
> For example, you can cast between arrays and objects, with no errors, but
> the type hints will still generate errors. I think this settles the
> consistency issue for me.
>
> John Crenshaw
> Priacta, Inc.
>
