Don't your arguments work equally well against type hinting for objects?
You have the same problems: if you screw something up in user code and
pass the wrong type, it fails at runtime. You also get 'random' failures
if you deserialise/read from config an object whose internal type
changed since it was serialised if you don't validate this (which you
usually don't). Yet we have object type hinting, because it is useful,
and it works OK most of the time. I think the same for enum type
hinting.
Ben.
On 24/02/11 1:00 PM, Stas Malyshev wrote:
Hi!
You can do it like this. When an enum is defined:
I'm not talking about implementation in the code of PHP engine. I'm talking
about
writing code with these things that wouldn't produce fatal errors in random
places
without you being able to prevent it and without checking before each function
call. Compiled languages deal with it easily because they check these things on
compile - if you try to send int variable where BlahBlah type is expected, the
compiler bails out and you know it's a problem. Dynamic languages don't work
that
way.
You'd just cast it to the enum type, at which point PHP would look up
the enum value in the internal array in the enum class to efficiently
retrieve the relevant strongly typed enum constant.
But the procedure loading the configs probably has no idea about your enums -
for
it it's just nmumbers. So you'd probably have to take the cast down close to the
actual call. At which time you could as well done the proper check and handle it
in an application-specific way.
I also suggest when type-hinting, if the type is integer or string where
an enum is expected, PHP attempts a cast before failing, to make this
more convenient.
Strict typing is not robust unless you can ensure your variables and method
returns have required types - either using compiler or manually checking.
Converting helps a little here but still you're putting into the language
something that is best handled on user-level since the language doesn't have
enough information to handle it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
