On 06/02/2008, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> Sam Barrow schrieb:
> > If anyone has any objections to a scalar type hint please raise a
> > valid point.
>
> Chris Stockton schrieb:
> > This library would probably have ~300(String) + ~110(Int)
> > ~40(Resource) ~30(Bool) ~10(Float) = 500 less function calls, and much
> > cleaner code if there was type hinting.
>
> I may be short-sighted here, but does type adding hinting not just push
> the problem to the library user? In strictly typed languages the
> compiler enforces type consistency, in PHP any type inconsistency yields
> a runtime error, thus forcing the library user to explicitly type cast,
> wrap every library call into a try-catch statement or use a runtime
> error handler (which in turn can throw an exception, taking us back to
> try-catch)?
Argh! You would only be short sighted if ...
1 - You didn't check the values or filter user input data and pushed
strings into every function/method.
2 - Internal variables where always instantiated in the wrong type
(i.e. $b_Flag = "1" sort of thing rather than $b_Flag = True;}
IF you input validate your data and you initialise your internal
variables with an appropriate type for their use, then no, you
wouldn't need to cast anything to use a library which uses type hints.
Why would you send a float to a string variable except for string
concatenation? (Maybe you didn't validate the user input?)
One either allows junk to be sent to our libraries and spend most of
the time cleaning it, or, by the use of a single NEW facility, we
force the users of the library to do it for us.
This is NOT stopping lazy coders, but it certainly helps a library not
have to deal with crap data.
function($i_Int) {
if(False === is_int($i_Int)) {
// perform some sort of error as the supplied data is useless.
}
}
vs.
function(int $i_Int) {
}
If I am using the type hints, then I expect the code to fail at
runtime if I supply "fred". I __EXPECT__ that. I have used the wrong
type. If I use a library and it says type hinting is used, I
__EXPECT__ the same failure.
The idea that we have things "that just work" and "just work forever"
because "that's how we've always done it" are not actually moving
forward.
Major facilities like Unicode have a serious impact on how we will
write our code. The whole debate about unicode_semantics is a good
example of trying to just makes things work as they used to with no
additional work from the userland developer or a real new facility
which requires proper understanding and some level of training.
Using type hinting is no where near as complicated or problematic. It
will encourage developers to right safer code. There should actually
be less code (none of that userland type checking going on).
> From an overall perspective on the PHP code, I would rather have the
> type checks _once_ inside the functions/methods, instead of multiple
> times on every call.
? Once inside the function? How do we cache the results?
If userland function x() has type checking (is_int(), etc,), then the
checking will be done every time the function is called.
If userland function x() has type hinting in the function declaration,
then the type checking will be done every time the function is called.
Hmm. I don't see the difference.
Except, userland code theoretically takes longer to process than c
code. So faster code and smaller code. Less to go wrong.
>
> Regards,
>
> Stefan
Regards,
Richard.
>
>
> --
> >e-novative> - We make IT work for you.
>
> e-novative GmbH - HR: Amtsgericht München HRB 139407
> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
>
> http://www.e-novative.de - GnuPG Key: 0x7DB67F7F
>
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
