Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52863
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain croscon.com from 66.46.182.54 cause and error)
Message-ID: <4DE8F971.8070606@croscon.com>
Date: Fri, 3 Jun 2011 11:10:41 -0400
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: internals@lists.php.net
References: <BANLkTi=1XwcGhy8UP_9gtkxGX-PqDfwxVQ@mail.gmail.com>	<BANLkTinCjPJTsKvUiFdXJQG4EB668Me_+g@mail.gmail.com> <BANLkTinemhsVsDM6eFzpB9vh6x-bbLdS_Q@mail.gmail.com>
In-Reply-To: <BANLkTinemhsVsDM6eFzpB9vh6x-bbLdS_Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Enum
From: marcel.esser@croscon.com (Marcel Esser)

On 6/3/2011 8:27 AM, Dennis Haarbrink wrote:
> As soon as I have my requested write permission in the rfc namespace i will
> update it.
>
> --
> Dennis Haarbrink
>
>
> 2011/6/3 Pierrick Charron<pierrick@webstart.fr>
>
>> Hi,
>>
>> The RFC was supposed to be a draft (i didn't really added it in the good
>> section) and was written more to introduce the idea and make people think
>> about it.
>> Feel free to update it with any idea, concern you may have.
>>
>> Pierrick
>>
>>
>> On 3 June 2011 03:26, Dennis Haarbrink<dhaarbrink@gmail.com>  wrote:
>>
>>> One thing I would really like to see in 5.4 is enums.
>>> There is already an RFC for that: https://wiki.php.net/rfc/enum
>>>
>>> This was discussed in february this year, but no consensus was reached.
>>> IIRC, the most notable problems were:
>>> - What is the 'value' of enum constant: string or int, user defined
>>> scalar,
>>> defaults
>>> - Ability to make enums more 'class like', some people wanted to be able
>>> to
>>> add methods.
>>>
>>> Another thing which was discussed (and I think most people agreed on
>>> that),
>>> but is not in the RFC: type hinting in method signatures.
>>>
>>>
>>> I think we should keep this simple proposal simple, let it be an enum in
>>> all
>>> its simplicity.
>>> The toughest part would be to decide what would be the default value. Some
>>> proposed to use the name of the constant, which is imho best for
>>> debuggability (i like this one the best), or an auto incrementing int,
>>> saying that it is better performance wise and which is more analog with
>>> mysql's enum type.
>>>
>>>
>>> So, to sum up:
>>> - Do we really need enum level methods?
>>> - Need to reach consensus on default values (strings vs auto inc. ints)
>>> - RFC needs to be updated, explaining the type hinting of enums in method
>>> signatures
>>>
>>>
>>>
>>> Regards,
>>> Dennis Haarbrink
>>>
>>
If I might raise the question, I am also really interested in how enums 
could respond across namespace. Personally, I am not entirely sure about 
the ability to add methods to enums. That sounds like a class, to me. 
However, the second example on the RFC of use-case, wherein the 
developer uses a class to contain constants, sounds to me like a 
namespacing issue. Would enums be objects that are within the scope of 
the namespace, like classes, or would they be global? I would personally 
favor they remain in the scope of the namespace. That removes the need 
to prefix them with any sort of pseudo-namespace (like a class, for 
example), and it prevents collisions, of course.

- M.