Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57971
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
Received-SPF: pass (google.com: domain of samuel.deal@gmail.com designates 10.229.77.131 as permitted sender) client-ip=10.229.77.131;
MIME-Version: 1.0
In-Reply-To: <4F457597.3060405@sugarcrm.com>
References: <CAG=uTXFQUY=EDb=ut97nNSm+m8sMQNRK-9YPcfb2quaoS246-g@mail.gmail.com>
	<CABBJUpd7XkDjckY-5=D6B=kouUYMrWvzMVnHR_Hch74oGWM-TQ@mail.gmail.com>
	<CAO8n+WJrqUguS4FSq==z9rF6iLoz3uXqSLBrrkY6yMBY9DrTWA@mail.gmail.com>
	<CALtuQzD6f_vcZiGi2HWdP8SSqf9744FucUC+4sX7PnGhOnh+rg@mail.gmail.com>
	<4F455C96.50706@gmail.com>
	<4F455E91.2060408@googlemail.com>
	<4F4570D6.8040003@gmail.com>
	<4F457597.3060405@sugarcrm.com>
Date: Thu, 23 Feb 2012 03:22:22 +0100
Message-ID: <CAG=uTXEWP4NaK1FbW2j_cNBpsf=LeSSc-NPVqWkx+fV6Ae1viw@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=002354470bfc7270b704b998505a
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
From: samuel.deal@gmail.com (Samuel Deal)

--002354470bfc7270b704b998505a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi !

First, thanks for all your replies.

I'll try to answer all questions, it'll be long.

#1. Should PHP have an enum implementation (not especially mine) ?

I think yes. We do not require it, there's nothing we can't do without.
However I think we need an intuitive and expressive syntax for this common
concept, a kind of syntax sugar, like "++" operator.

There's a lot of (beginners) php devs who tried to express this concept
with serialized constants or other ugly practices.
I don't say we must provide a language native structure for everything
those devs make bad, they need to learn.
Just, any devs I know, who came to PHP from another language, soon thought
"How can I emulate enums"

We do not have to copy other language; if someone has an expressive syntax
for a more advanced concept, I'm in.

Pros and cons:
+ expressiveness
+ performance for enum built-in functions
- another keyword
- (very very) little engine slowdown
- work to do (but it could be a small hack, easy to maintains, and I'm ok
do it)



#2. Enum values should be objects or scalars ?

I choose scalars for several reasons:
- more in "=C3=A0 la PHP" style, not strictly typed (but we can provide bui=
lt-in
functions to do checks)
- it's easier to communicate (to save into db, to retrieve from http post
queries, etc...)
- serialization is faster an shorter
- it's easier to migrate from existing PHP code based on class constant to
enum.
- less memory consuming

I didn't see real drawbacks of using scalars instead of objects.
Except if you wanna have a really really strict typing.
( By strict typing I mean something like that:
myEnum::foo =3D=3D 1                    // =3D> false
myEnum::foo =3D=3D myEnum(1)     // =3D> true
)


#3. Enum values: int or string ? Do we need an explicit values syntax ?

I chose int, because:
Most of time, in our code, we would write enum names ("myEnum::foo").
Code would be expressive, with a shorter memory footprint.
You don't have to provide any value if you didn't need it.
Less often you'll need string representation, but you can easily get it
(in foreach or with enum built-in functions, myEnum::name($value) in my
proposal)

In addition, sometime you have to deal with other programs which required
numeric values.
In that case you can use explicit numeric values without writing a mapping
function?

Issues happened when you have to change the enum declaration, and have
somewhere (database, session, etc...) values stored you can't easily change=
.
If it's INT-based:
when you add or remove a value, you have to be careful not to change
auto-incremented values.
That's why providing an explicit value syntax is useful.
If it's STRING-based:
when a functionality is bad-named ("We agree about this, I won't change it"
-- the client --), you're stuck with this old name all over your code
forever.


#4. What's wrong with class constants ?

Nothing.
My proposal is only a syntactic sugar to declare, iterate and manipulate a
kind of class constants.


#5. What about SplEnum ?

I think it's a good alternative. If finally my RFC is rejected, I hope this
will be include in official php version.
But it's a strictly typed approach, and I prefer the other one (see #2)


#6. Why didn't you push this RFC on the wiki.

First, I had a lot of respect for work done, and I didn't want to override
previous RFC
Then, I'm new here, and there's no explanations in that situation in the
RFC about RFCs.
Finally, I don't have rights for that.

Tell me what you want me to do about this.



I hope I haven't forgotten a question.

Thanks for reading this long post.
Thanks for arguing.

Regards
--=20
Samuel DEAL
samuel.deal@gmail.com

--002354470bfc7270b704b998505a--