# [RFC] Enum proposal (yet another)

- Thread: https://externals.io/message/57928
- Original archive: https://news-web.php.net/php.internals/57928
- Started by Samuel Deal on 2012-02-22T04:45:32+00:00
- Messages: 62
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/57928.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #57928 — Samuel Deal — 2012-02-22T04:45:32+00:00

URL: https://externals.io/message/57928#57928

Hi all,

I really missed enums in PHP,
So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks
-- 
Samuel Déal
samuel.deal@gmail.com

---

## #57929 — Laruence — 2012-02-22T05:14:12+00:00

URL: https://externals.io/message/57928#57929 · In reply to: #57928

> Hi all,
>
> I really missed enums in PHP,
Why? we have class constant.

thanks
> So after reading I tryed to synthetise the various views.
>
> You can find a draft here :
> https://github.com/SamNrique/php-src/wiki/RFC-draft
> (I can't write on the wiki, and perhaps it's better to finish the
> discussion first)
>
> There's an implementation with this draft.
> I'd love to have feedbacks because it's my first php-core hack.
>
> Thanks
> --
> Samuel Déal
> samuel.deal@gmail.com



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

---

## #57932 — Charlie Somerville — 2012-02-22T06:02:16+00:00

URL: https://externals.io/message/57928#57932 · In reply to: #57929

Right, but enums could possibly be a lot richer than class constants are
now.

They could be a type where the only values are what's defined in the enum.
This could be used with type hinting:

    enum Foo {
        A,
        B,
        C
    }

    function bar(Foo $x) {
        // ...
    }

There'd be no need to do any manual checking that $x is a valid value.

Perhaps enum values could also be casted back to strings:

    (string)Foo::B; // "B"

Sure, this is the kind of stuff that's possible in other ways already, but
first class support always helps.


> On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal <samuel.deal@gmail.com>
> wrote:
> > […]
> Why? we have class constant.
>
> thanks
> > […]
>
>
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/

---

## #57937 — Sebastian Krebs — 2012-02-22T08:37:21+00:00

URL: https://externals.io/message/57928#57937 · In reply to: #57932

2012/2/22 Charlie Somerville <charlie@charliesomerville.com>

> Right, but enums could possibly be a lot richer than class constants are
> now.
>
> They could be a type where the only values are what's defined in the enum.
> This could be used with type hinting:
>
>    enum Foo {
>        A,
>        B,
>        C
>    }
>
>    function bar(Foo $x) {
>        // ...
>    }
>


class MyEnum {
    const FOO = 'foo';
    const BAR = 'bar';
    private $value;
    public function __construct ($value) {
        if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
        $this->value = $value;
    }
    public function __toString () { return $this->value; }
}


function doSomething (MyEnum $foo) { /* code */ }


What I wanted to say: I don't see, what is not possible already?



>
> There'd be no need to do any manual checking that $x is a valid value.
>
> Perhaps enum values could also be casted back to strings:
>
>    (string)Foo::B; // "B"
>
> Sure, this is the kind of stuff that's possible in other ways already, but
> first class support always helps.
> 
>
> > […]

---

## #57938 — Charlie Somerville — 2012-02-22T08:45:40+00:00

URL: https://externals.io/message/57928#57938 · In reply to: #57937

My point is that *although* it's certainly possible to do almost everything I want already, I should not have to write all that boilerplate for each enum.

I would much prefer to write something like 'enum { A, B, C }' rather than write a full class for the enum, duplicate each enum value multiple times (your example repeats 'foo' and 'bar' three times each), overload the __toString() magic method, do manual error handling in the constructor, etc.

Since PHP provides no way to overload the equality operator, any solution that tries to emulate enums as Samuel or I have written about will be flawed.  




> 2012/2/22 Charlie Somerville <charlie@charliesomerville.com (mailto:charlie@charliesomerville.com)>
>  
> > […]
>  
>  
>  
> class MyEnum {
> const FOO = 'foo';
> const BAR = 'bar';
> private $value;
> public function __construct ($value) {
> if (!in_array($value, array(self::FOO, self::BAR)) throw new
> UnexpectedValueException;
> $this->value = $value;
> }
> public function __toString () { return $this->value; }
> }
>  
>  
> function doSomething (MyEnum $foo) { /* code */ }
>  
>  
> What I wanted to say: I don't see, what is not possible already?
>  
>  
>  
> > […]

---

## #57939 — Nikita Popov — 2012-02-22T08:50:33+00:00

URL: https://externals.io/message/57928#57939 · In reply to: #57928

What about SplEnum? (http://php.net/splenum)

It's part of the SPL types extension, but it could probably be also
moved to core.

Nikita


> Hi all,
>
> I really missed enums in PHP,
> So after reading I tryed to synthetise the various views.
>
> You can find a draft here :
> https://github.com/SamNrique/php-src/wiki/RFC-draft
> (I can't write on the wiki, and perhaps it's better to finish the
> discussion first)
>
> There's an implementation with this draft.
> I'd love to have feedbacks because it's my first php-core hack.
>
> Thanks
> --
> Samuel Déal
> samuel.deal@gmail.com

---

## #57947 — Eitan Mosenkis — 2012-02-22T13:57:58+00:00

URL: https://externals.io/message/57928#57947 · In reply to: #57928

I think that your proposal looks good, but I'd like to suggest a few
changes. First of all, I'd like to see the association with integers
removed. An enum instance shouldn't just be a name for an integer, it
should be more like a singleton instance of a special kind of class
that can only ever have a predefined set of named instances. There
should be no value associated with it.

Secondly, there already exists the capacity for arbitrary classes to
be used in foreach and count you just have to implement Iterator and
Countable. Other interfaces that all enums might want to implement
automatically are ArrayAccess and Serializable. This would just
require the enum itself to be an object (maybe of type enum or
something) such that it can implement the relevant methods.

http://www.php.net/manual/en/class.iterator.php
http://php.net/manual/en/class.countable.php


> Hi all,
>
> I really missed enums in PHP,
> So after reading I tryed to synthetise the various views.
>
> You can find a draft here :
> https://github.com/SamNrique/php-src/wiki/RFC-draft
> (I can't write on the wiki, and perhaps it's better to finish the
> discussion first)
>
> There's an implementation with this draft.
> I'd love to have feedbacks because it's my first php-core hack.
>
> Thanks
> --
> Samuel Déal
> samuel.deal@gmail.com

---

## #57961 — keisial@gmail.com — 2012-02-22T21:22:30+00:00

URL: https://externals.io/message/57928#57961 · In reply to: #57937

> class MyEnum {
>     const FOO = 'foo';
>     const BAR = 'bar';
>     private $value;
>     public function __construct ($value) {
>         if (!in_array($value, array(self::FOO, self::BAR)) throw new
> UnexpectedValueException;
>         $this->value = $value;
>     }
>     public function __toString () { return $this->value; }
> }
>
>
> function doSomething (MyEnum $foo) { /* code */ }
>
>
> What I wanted to say: I don't see, what is not possible already?

I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
not doSomething(new MyEnum(MyEnum::FOO));

+1 for adding enums (although I'm open to variations from that exact
proposal).

---

## #57965 — Dmitri Snytkine — 2012-02-22T21:43:41+00:00

URL: https://externals.io/message/57928#57965

For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum, and
why certain things are better with enums.

http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

I think enums will be beneficial to php, but will add one more features that
people not familiar with it will have to learn about.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"


-----Original Message-----
From: Sebastian Krebs [mailto:krebs.seb@googlemail.com] 
Sent: Wednesday, February 22, 2012 4:31 PM
To: PHP internals list
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Am 22.02.2012 22:22, schrieb Ángel González:
> 
> > […]
>
> I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
> not doSomething(new MyEnum(MyEnum::FOO));




// The class file
class MyEnum {
      public static $FOO;
      public static $BAR;
      const FOO = 'foo';
      const BAR = 'bar';
      private $value;
      public function __construct ($value) {
          if (!in_array($value, array(self::FOO, self::BAR)) throw new 
UnexpectedValueException;
          $this->value = $value;
      }
      public function __toString () { return $this->value; }
}
/* static code block */ {
   // As long as PHP doesn't support "constant references" (;))
   // (--> constants with objects or arrays)
   MyEnum::$FOO = new MyEnum(MyEnum::FOO);
   MyEnum::$BAR = new MyEnum(MyEnum::BAR);
}
// End class file

// Somewhere deep within some other code
doSomething (MyEnum::$FOO);





However, I can't see, what is the big thing, that isn't currently not 
possible (except any "I want"-argumentation :X)

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


>
> +1 for adding enums (although I'm open to variations from that exact
> proposal).

---

## #57966 — Kris Craig — 2012-02-22T22:13:19+00:00

URL: https://externals.io/message/57928#57966 · In reply to: #57965

While I'm a huge fan of Github, why did you decide to host your RFC there
instead of on the PHP wiki?  I realize there's an older proposal there
right now, but that's from 2010 and seems to be dead in the water.  Even if
yours is just a draft, the wiki is designed to be able to accommodate
progressive revisions.

I only mention this because I think it definitely helps to have one central
place where all the RFCs can be looked at, including the draft ones.  At
very least, could you add a link to your RFC on the wiki page?  I'd also
like to throw another idea out there:  Should we consider amending the RFC
procedures to allow for expiration of old RFCs that have never been moved
to the voting stage?  I was wondering because that older enum RFC is still
"Under Discussion" and last modified nearly a year ago; actually proposed
nearly 2 years ago.  It seems to have been abandoned so I'm just curious if
maybe we should have some process in place to categorize that.


Regarding this particular RFC, personally I've never seen the need to use
enums, but it certainly does sound like something that would add
convenience and make that one less feature other languages have that PHP
doesn't.  So I don't personally have any objection so long as the
implementation is solid.

--Kris


On Wed, Feb 22, 2012 at 1:43 PM, Dmitri Snytkine <
dsnytkine@ultralogistics.com> wrote:

>
> For those who keep saying "but this can already be done in php", here is a
> pretty good article.
> Long time ago enums were not available in Java also, so this article
> explains that yes, thigs can technically could be done before the enum, and
> why certain things are better with enums.
>
>
> http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html
>
> I think enums will be beneficial to php, but will add one more features
> that
> people not familiar with it will have to learn about.
>
> Dmitri Snytkine
> Web Developer
> Ultra Logistics, Inc.
> Phone: (888) 220-4640 x 2097
> Fax: (888) 795-6642
> E-Mail: dsnytkine@ultralogistics.com
> Web: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. Provider in 2011"
>
>
> -----Original Message-----
> From: Sebastian Krebs [mailto:krebs.seb@googlemail.com]
> Sent: Wednesday, February 22, 2012 4:31 PM
> To: PHP internals list
> Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
>
> Am 22.02.2012 22:22, schrieb Ángel González:
> > […]
>
>
>
>
> // The class file
> class MyEnum {
>      public static $FOO;
>      public static $BAR;
>       const FOO = 'foo';
>      const BAR = 'bar';
>      private $value;
>      public function __construct ($value) {
>          if (!in_array($value, array(self::FOO, self::BAR)) throw new
> UnexpectedValueException;
>          $this->value = $value;
>      }
>      public function __toString () { return $this->value; }
> }
> /* static code block */ {
>   // As long as PHP doesn't support "constant references" (;))
>   // (--> constants with objects or arrays)
>   MyEnum::$FOO = new MyEnum(MyEnum::FOO);
>   MyEnum::$BAR = new MyEnum(MyEnum::BAR);
> }
> // End class file
>
> // Somewhere deep within some other code
> doSomething (MyEnum::$FOO);
>
>
>
>
>
> However, I can't see, what is the big thing, that isn't currently not
> possible (except any "I want"-argumentation :X)
>
> Sidenote, according your examples above on how you want call functions:
> Considered using normal constants?
>
>
> > […]

---

## #57968 — keisial@gmail.com — 2012-02-22T23:03:39+00:00

URL: https://externals.io/message/57928#57968 · In reply to: #57966

> While I'm a huge fan of Github, why did you decide to host your RFC there
> instead of on the PHP wiki? (...)
Samuel doesn't have a wiki accout.
I agree he should get one and continue the proposal there.

---

## #57969 — Stas Malyshev — 2012-02-22T23:07:03+00:00

URL: https://externals.io/message/57928#57969 · In reply to: #57965

Hi!

> For those who keep saying "but this can already be done in php", here is a
> pretty good article.
> Long time ago enums were not available in Java also, so this article
> explains that yes, thigs can technically could be done before the enum, and
> why certain things are better with enums.
>
> http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

One note here: Java is a statically typed compiled language. PHP is not. 
So many arguments regarding type safety, etc. which are completely valid 
in regards to Java have no validity in regard to PHP. I understand that 
some people want to import some bits from strictly typed languages, 
imagining that this will provide them with benefits that statically 
typed languages have, namely compile-time safety checks, etc. This does 
not work as well in dynamic languages. Note for example that neither 
Ruby nor Python have enums, though you can do similar things there.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #57970 — Stas Malyshev — 2012-02-22T23:09:11+00:00

URL: https://externals.io/message/57928#57970

Hi!

> > […]
> 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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #57971 — Samuel Deal — 2012-02-23T02:22:22+00:00

URL: https://externals.io/message/57928#57971 · In reply to: #57970

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 "à la PHP" style, not strictly typed (but we can provide built-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 == 1                    // => false
myEnum::foo == myEnum(1)     // => 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
-- 
Samuel DEAL
samuel.deal@gmail.com

---

## #57973 — Dmitri Snytkine — 2012-02-23T13:39:30+00:00

URL: https://externals.io/message/57928#57973

True but it will have with type hinting, making code more 'bullet proof'

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"


-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com] 
Sent: Wednesday, February 22, 2012 6:07 PM
To: Dmitri Snytkine
Cc: 'Sebastian Krebs'; 'PHP internals list'
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Hi!

> For those who keep saying "but this can already be done in php", here is a
> pretty good article.
> Long time ago enums were not available in Java also, so this article
> explains that yes, thigs can technically could be done before the enum,
and
> why certain things are better with enums.
>
>
http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

One note here: Java is a statically typed compiled language. PHP is not. 
So many arguments regarding type safety, etc. which are completely valid 
in regards to Java have no validity in regard to PHP. I understand that 
some people want to import some bits from strictly typed languages, 
imagining that this will provide them with benefits that statically 
typed languages have, namely compile-time safety checks, etc. This does 
not work as well in dynamic languages. Note for example that neither 
Ruby nor Python have enums, though you can do similar things there.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #57975 — Anthony Ferrara — 2012-02-23T14:32:34+00:00

URL: https://externals.io/message/57928#57975 · In reply to: #57973

If you're going to go that far, why not make a flyweight enum type?
(Basically what's described here: http://c2.com/cgi/wiki?FlyweightEnum
)...

Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit).  If you used a flyweight, you could literally type-hint.

It's 100% possible right now to do it that way, as demonstrated here:
https://gist.github.com/1893073

But with the lack of const object references, we have to resort to a
few dirty tricks (such as using __callStatic).  Additionally, it
requires hard-coding the values in two places (one as a class, and the
other as the reference in the `new` lines).

It also has the benefit of working with the object system that is already built.

Perhaps it would be worth while adding syntactic sugar to the parser
to convert the enum declaration into something like this, so that the
changes would be localized...

enum MyEnum {
    MyFirstValue,
    MySecondValue,
    MyThirdValue
}

Which would then be converted into basically what I have in that gist,
a class internally which would then work with traditional OO system to
produce the flyweight enum for us (so we wouldn't have to write all
that boiler plate every time we wanted an enum)...

Just a thought...

Anthony

On Thu, Feb 23, 2012 at 8:39 AM, Dmitri Snytkine
<dsnytkine@ultralogistics.com> wrote:
> True but it will have with type hinting, making code more 'bullet proof'
>
> Dmitri Snytkine
> Web Developer
> Ultra Logistics, Inc.
> Phone: (888) 220-4640 x 2097
> Fax: (888) 795-6642
> E-Mail: dsnytkine@ultralogistics.com
> Web: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. Provider in 2011"
>
>
> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Wednesday, February 22, 2012 6:07 PM
> To: Dmitri Snytkine
> Cc: 'Sebastian Krebs'; 'PHP internals list'
> Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
>
> Hi!
>
> > […]
> and
> > […]
> http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html
>
> One note here: Java is a statically typed compiled language. PHP is not.
> So many arguments regarding type safety, etc. which are completely valid
> in regards to Java have no validity in regard to PHP. I understand that
> some people want to import some bits from strictly typed languages,
> imagining that this will provide them with benefits that statically
> typed languages have, namely compile-time safety checks, etc. This does
> not work as well in dynamic languages. Note for example that neither
> Ruby nor Python have enums, though you can do similar things there.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #57977 — Stas Malyshev — 2012-02-23T18:34:46+00:00

URL: https://externals.io/message/57928#57977 · In reply to: #57975

Hi!

> If you're going to go that far, why not make a flyweight enum type?
> (Basically what's described here: http://c2.com/cgi/wiki?FlyweightEnum
> )...
>
> Right now, it's a hack to get typing in place to let you pass an
> integer where a class is defined (the public function foo(MyEnum
> $enum) bit).  If you used a flyweight, you could literally type-hint.

Again, it looks like you are trying to introduce strict typing into PHP. 
I do not think it's a good idea, for the reasons I described at length 
in previous discussions, but you're free to try.
However, I don't see how changing the language to make it easier to do 
partial backdoor strict typing is a good idea. Bringing Java as an 
example only supports this point.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #57979 — keisial@gmail.com — 2012-02-23T19:01:29+00:00

URL: https://externals.io/message/57928#57979 · In reply to: #57970

> Hi!
>
> > […]
>
> 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).

Best regards

---

## #57981 — Kris Craig — 2012-02-23T19:21:34+00:00

URL: https://externals.io/message/57928#57981 · In reply to: #57977

Hmm I think Stas makes a good point.  One of the allures of PHP,
particularly for web developers without any programming experience, is its
flexibility.  Strict typing would certainly negate that.

If I may be so bold, should we perhaps expand the scope of this discussion
to address the larger question of whether or not strict typing should be
introduced into PHP, and if so, in what form and to what extent?  It seems
to me that we must answer that question before we can answer the enum one.

Specifically, these are the questions that come to mind:

   1. Is strict typing something that we should seriously consider
   implementing at some point in the foreseeable future?
   2. If "yes", should it be an "always on" type of thing or a toggleable
   thing?
   3. If toggleable, should this be defined at the config level, the script
   level, or both?
   4. Depending on your answers to 1 - 3, what would be the advantages to
   this approach?
   5. Depending on your answers to 1 - 3, what would be the disadvantages
   to this approach?

If y'all wouldn't mind humoring me, would you be willing to send your
answers to these questions in your next reply?  I think it would help us to
bring some objective clarity to this issue as well as guage what the
current consensus is, if there is one.


As such, here are the answers that come to my mind:

   1. Yes, I think the idea has enough merit for further consideration.
   2. Definitely toggleable!  It would probably have to be "off" by default
   for the sake of backwards compatibility.
   3. I'm not sure, but my inclination would be both.  Perhaps an INI value
   that can easily be set at the script level, similar to max_execution_time.
   4. Advantages:
      - Strictly-typed code is much easier to read and follow.
      - Programmers experienced in other languages like C# and Java would
      find PHP much more appealing.
      - It would allow for much more simplified code with fewer sanity
      checks at the script-level.
         - For example, I've been working on a Drupal-based project that
         was written by another person (it's work-related so I'm distorting the
         details so as not to breach the NDA).  This person had the
annoying habit
         of "sending" variables (JSON-encoded/decoded from a remote
hub that he also
         wrote) with inconsistent types.  For example, the "progress"
key could be a
         multidimensional array, a string, NULL, a boolean, and in one
rare case
         even an object pointer.  But MOST of the time, it's an array,
and the way
         the architecture is setup, there's no way to anticipate what
type it will
         be except to test for it.  So, rather than simply being able
to check for
         something like, $progress["percent"], I instead have to do a
ton of sanity
         checks to first make sure it's the type of variable I'm
looking for at any
         particular moment.
      - Frequently requested features, like enums, would no longer be
      impractical.
      - Seasoned PHP developers who want to venture into compiled
      programming languages could first enable strict typing as a
stepping stone,
      reducing the learning curve.
   5. Disadvantages:
      - It would probably be a fairly large undertaking to implement.
      - This could result in a sort of pseudo-parallel set of languages
      emerging within PHP core, since some things, like enums, would presumably
      be dependent upon strict typing being enabled.
      - Though it would allow for simpler, easier to follow code, it
      probably(?) wouldn't actually add any practical functionality in terms of
      what PHP can actually *do* that it doesn't have already in other
      forms.

Those are my thoughts.  It's too early for me to draw any conclusions on
whether this should be implemented or not.  I'd like to see what the rest
of you have to say on the subject.

If you wouldn't mind jumping through my hoops and answering the above
questions as I just did, I think that would help us all to quantify this
from different angles and arrive at a much clearer understanding as to the
implications involved.  =)

--Kris


On Thu, Feb 23, 2012 at 10:34 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
>
>  If you're going to go that far, why not make a flyweight enum type?
> > […]
>
> Again, it looks like you are trying to introduce strict typing into PHP. I
> do not think it's a good idea, for the reasons I described at length in
> previous discussions, but you're free to try.
> However, I don't see how changing the language to make it easier to do
> partial backdoor strict typing is a good idea. Bringing Java as an example
> only supports this point.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #57983 — John LeSueur — 2012-02-23T19:37:42+00:00

URL: https://externals.io/message/57928#57983 · In reply to: #57981

Previous discussions have covered the probability that strict typing and
dynamic typing can't coexist, because strict typing ends up pushing itself
further up the call tree. An ini setting to change from one to the other
will not solve that problem. Not sure that it says anything about enums,
but strict vs. dynamic typing is a hot topic that probably won't get any
agreement here. The previous discussions are just too recent, and it's not
likely anyone has changed their mind.



> Hmm I think Stas makes a good point.  One of the allures of PHP,
> particularly for web developers without any programming experience, is its
> flexibility.  Strict typing would certainly negate that.
>
> If I may be so bold, should we perhaps expand the scope of this discussion
> to address the larger question of whether or not strict typing should be
> introduced into PHP, and if so, in what form and to what extent?  It seems
> to me that we must answer that question before we can answer the enum one.
>
> Specifically, these are the questions that come to mind:
>
>   1. Is strict typing something that we should seriously consider
>   implementing at some point in the foreseeable future?
>   2. If "yes", should it be an "always on" type of thing or a toggleable
>   thing?
>   3. If toggleable, should this be defined at the config level, the script
>   level, or both?
>   4. Depending on your answers to 1 - 3, what would be the advantages to
>   this approach?
>   5. Depending on your answers to 1 - 3, what would be the disadvantages
>   to this approach?
>
> If y'all wouldn't mind humoring me, would you be willing to send your
> answers to these questions in your next reply?  I think it would help us to
> bring some objective clarity to this issue as well as guage what the
> current consensus is, if there is one.
>
>
> As such, here are the answers that come to my mind:
>
>   1. Yes, I think the idea has enough merit for further consideration.
>   2. Definitely toggleable!  It would probably have to be "off" by default
>   for the sake of backwards compatibility.
>   3. I'm not sure, but my inclination would be both.  Perhaps an INI value
>   that can easily be set at the script level, similar to
> max_execution_time.
>   4. Advantages:
>      - Strictly-typed code is much easier to read and follow.
>      - Programmers experienced in other languages like C# and Java would
>      find PHP much more appealing.
>      - It would allow for much more simplified code with fewer sanity
>      checks at the script-level.
>         - For example, I've been working on a Drupal-based project that
>         was written by another person (it's work-related so I'm distorting
> the
>         details so as not to breach the NDA).  This person had the
> annoying habit
>         of "sending" variables (JSON-encoded/decoded from a remote
> hub that he also
>         wrote) with inconsistent types.  For example, the "progress"
> key could be a
>         multidimensional array, a string, NULL, a boolean, and in one
> rare case
>         even an object pointer.  But MOST of the time, it's an array,
> and the way
>         the architecture is setup, there's no way to anticipate what
> type it will
>         be except to test for it.  So, rather than simply being able
> to check for
>         something like, $progress["percent"], I instead have to do a
> ton of sanity
>         checks to first make sure it's the type of variable I'm
> looking for at any
>         particular moment.
>      - Frequently requested features, like enums, would no longer be
>      impractical.
>      - Seasoned PHP developers who want to venture into compiled
>      programming languages could first enable strict typing as a
> stepping stone,
>      reducing the learning curve.
>   5. Disadvantages:
>      - It would probably be a fairly large undertaking to implement.
>      - This could result in a sort of pseudo-parallel set of languages
>      emerging within PHP core, since some things, like enums, would
> presumably
>      be dependent upon strict typing being enabled.
>      - Though it would allow for simpler, easier to follow code, it
>      probably(?) wouldn't actually add any practical functionality in
> terms of
>      what PHP can actually *do* that it doesn't have already in other
>      forms.
>
> Those are my thoughts.  It's too early for me to draw any conclusions on
> whether this should be implemented or not.  I'd like to see what the rest
> of you have to say on the subject.
>
> If you wouldn't mind jumping through my hoops and answering the above
> questions as I just did, I think that would help us all to quantify this
> from different angles and arrive at a much clearer understanding as to the
> implications involved.  =)
>
> --Kris
>
>
> On Thu, Feb 23, 2012 at 10:34 AM, Stas Malyshev <smalyshev@sugarcrm.com
> > […]
>
> > […]
> http://c2.com/cgi/wiki?**FlyweightEnum<
> http://c2.com/cgi/wiki?FlyweightEnum>
> > […]
> I
> > […]
> example
> > […]

---

## #57985 — keisial@gmail.com — 2012-02-23T20:21:11+00:00

URL: https://externals.io/message/57928#57985

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.


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

---

## #57987 — Kris Craig — 2012-02-23T21:59:55+00:00

URL: https://externals.io/message/57928#57987 · In reply to: #57983

Could you elaborate on this?  So long as that setting cannot be changed
midway through a script or its includes (i.e. the stack must be "all
strict" or "all dynamic"), I can't think of any reason why that would not
be feasible.

At some point, it probably wouldn't hurt for us to at least start thinking
about what will be going into PHP 6.  Seems to me that something
fundamental like this would be an appropriate starting point, much like the
shift from procedural to OO focus largely defined PHP 5.

--Kris


On Thu, Feb 23, 2012 at 11:37 AM, John LeSueur <john.lesueur@gmail.com>wrote:

> Previous discussions have covered the probability that strict typing and
> dynamic typing can't coexist, because strict typing ends up pushing itself
> further up the call tree. An ini setting to change from one to the other
> will not solve that problem. Not sure that it says anything about enums,
> but strict vs. dynamic typing is a hot topic that probably won't get any
> agreement here. The previous discussions are just too recent, and it's not
> likely anyone has changed their mind.
>
> 
>
> > […]

---

## #57988 — keisial@gmail.com — 2012-02-23T22:30:25+00:00

URL: https://externals.io/message/57928#57988 · In reply to: #57987

> Could you elaborate on this?  So long as that setting cannot be changed
> midway through a script or its includes (i.e. the stack must be "all
> strict" or "all dynamic"), I can't think of any reason why that would not
> be feasible.
>
> --Kris
I'm afraid that would create a split between code-for-config-A and
code-for-config-B.

---

## #57989 — Kris Craig — 2012-02-23T22:49:40+00:00

URL: https://externals.io/message/57928#57989 · In reply to: #57988

Yeah I agree, that was one of the things I listed under "disadvantages" lol.

I guess my question is:  Does this constitute a prohibitive problem, or is
it something that we can stomach?

I mean, if you think about it, that's really what we're talking about
anyway, right?  After all, when you're writing any application, you're
either going to be writing it with strict typing or you're going to be
writing it with dynamic typing.  The only difference here is that coders
with either preference will both find PHP accommodating to their style.


Similarly, a somewhat weaker argument could be made that, in PHP 5, you're
either coding for procedural design or for OO design (technically you could
do both, but I wouldn't wanna touch that codebase with a ten foot poll
lol).  The only difference here is that there would be a config setting to
tell the interpreter which is which.

--Kris


2012/2/23 Ángel González <keisial@gmail.com>

> 
> > […]
> I'm afraid that would create a split between code-for-config-A and
> code-for-config-B.

---

## #57990 — Matti Bickel — 2012-02-23T23:07:47+00:00

URL: https://externals.io/message/57928#57990 · In reply to: #57989

[dynamic vs strict typing via config setting]
> Yeah I agree, that was one of the things I listed under "disadvantages" lol.
> 
> I guess my question is:  Does this constitute a prohibitive problem, or is
> it something that we can stomach?

As a user of PHP: this would be totally confusing. To be honest that
feels like asking Haskell to become procedural on the push of a button.
It's a switch of paradigma. If I wanted that, I'd choose another language.

Also: what the last RFC on type checking
(https://wiki.php.net/rfc/typechecking and the ml) said.

---

Next page: https://externals.io/message/57928.md?page=2