On 05/02/2008, Sam Barrow <[EMAIL PROTECTED]> wrote:
> Hey, I have an idea.
> We can appeal to the PHP developers to simply include the "scalar" type
> hint.
>
> They can't argue that this goes against type juggling, as the four
> scalar types can juggle, and this allows any of them.
>
> Anyone who is against this must also be against the array type hint, it
> is pretty much the same just in reverse.
>
> What do you think?
>
> On Tue, 2008-01-08 at 09:41 +0000, Richard Quadling wrote:
> > On 07/01/2008, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> > > Robert Cummings schrieb:
> > > > The onus should be on consumers of my API to use it properly, not on me
> > > > to jump through hoops to make sure they gave me the correct data at
> > > > every step of the way. I stopped holding hands in grade 3 or so.
> > >
> > > Still you force any defensive coder to repeat explicit type checks and
> > > type casts all over whenever one of your API functions is called.
> > >
> > > Regards,
> > >
> > > Stefan
> > >
> >
> > This argument implies that the coder constantly shifts type on their
> > variables.
> >
> > If I have a counter, I'll use an integer. I'll initialise it to 0. I
> > __CAN__ use a string of "0", but as soon as I say +1 it is juggled an
> > integer until some other use juggles it to something else.
> >
> > The only time I see auto type juggling useful (for internal data not
> > user input) is in string concatenation and then it fails for boolean
> > types (""/"1" rather than "0"/"1" or even better "true"/"false"). But
> > then, it is only the result of the juggle that is used. The original
> > variable isn't juggled.
> >
> > Type juggling is a great thing, but next to useless if you are a
> > "defensive coder".
> >
> > You know that converting from type a to type b MAY result in data loss
> > ("1 defensive coder" + 1 = 2, not "2 defensive coder", so you rarely
> > do it. Instead you will use functions to absolutely confirm the
> > conversion and check values.
> >
> > That's defensive.
> >
> >
> > From what I can tell this is what is being asked for.
> >
> > 1 - Scalar type hints act as type jugglers at the interface of the
> > function/method rather than having type checking code in the
> > function/method.
> >
> > You will still need to have value checks if they are appropriate.
> >
> > So, function x(string $s, int $i) will get a string and an integer, no
> > matter what is sent.
> >
> > Thinking about this, simply because we all know PHP __CAN__ type
> > juggle, there is no need for any errors/warnings/notices on scalar
> > types. It will be up to the API developer to make sure appropriate
> > values are supplied (if necessary), so this reduces the type checking.
> >
> >
> > Richard.
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
I think allowing the the hints and them to be enforced if E_STRICT is
set is the way to go.
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
