Am 23.02.2012 21:21, schrieb Ángel González:
I don't see your point, Sebastian.
And
| $studipNamedVariable = Databases::Mysql;
| // ... much code
| database_select($stupidNamedVariable, $sql);
is better? The problem here seems to be more the developer, that
avoids the use of constants, then less the missing enums.
You can obviously do weird things, as with in any feature. In this case
you bring up, I see little sense in passing enums in variables, unless
that comes itself from a parameter for that function, or comes from an
external source, like a configuration data.
Yes. You just say "unless...", but I don't think, that both are very
uncommon cases. Especially databases are configured. And values and
variables are often passed to other methods and functions.
If you use a constant like
| Databases::Mysql = 1024;
the call
| database_select(Database::IDontExists, $sql);
will fail too. Other examples, that supports type hints, can be found
in other mails around here.
Yes. With a parser error as IDontExists doesn't belong to Database enum.
How does it relate with assigning 1024 to Databases::Mysql ?
That
| Database::IDontExists
will raise a "Undefined class constant 'IDontExists'" fatal. Thats
completely independent from the type of the (other, existing) constants
of "Database". The only difference to a specialized Enum-type I see
_here_ is, that there will be a different error message.
I don't want to repeat myself, but you already answered on mails, that
showed solutions _with_ type hinting. That one above was a simplified
example, but it works too and it works fine (as long as developers are
able to use constants :)).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
