Re: [RFC] Enum proposal (yet another)

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 :)).