Re: [RFC] Enum proposal (yet another)

From: Date: Thu, 23 Feb 2012 19:06:03 +0000
Subject: Re: [RFC] Enum proposal (yet another)
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
Am 23.02.2012 20:01, schrieb Ángel González:

On 23/02/12 00:09, Stas Malyshev wrote:

Hi!


Sidenote, according your examples above on how you want call
functions: Considered using normal constants?

How can I do type hinting with them?


You should not. PHP is not a strictly typed language, so if you want
strictly typed function you'll get in trouble, for the same reasons
why strict scalar typing wasn't a good idea - you may want to re-read
these discussions.

I disagree.
It is arguable whether having


enum Databases { MySQL, Postgres, Oracle }
enum Colors { Red, Green, Blue }

database_select(Colors::Red, $sql);


should give an error for a Databases type hint on the first parameter,
as it can be converted (that's a soft vs strict typing issue).

However, such typehint should avoid a call like:

database_select(1024, $sql);


with which the function can't do anything sensible with (other than
returning an error if it does its own checking).


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




Best regards

Thread (70 messages)

« previous php.internals (#57980) next »