On 09/23/2015 02:19 PM, Rowan Collins wrote:
The internal implementation can never be quite as simple as an IS_LONG
zval if we want to provide anything at all beyond a C-style enum. I for
one do not want Days::MONDAY === Months::JANUARY to return true, and nor
should typeof(Days::MONDAY) return "
Jefferson Gonzalez wrote on 22/09/2015 20:28:
Is also worth noting that if you keep performance in mind, enums whith
values represented as integers should be a much more
performant/efficient implementation since it would require less cpu
cycles and memory to build and read them. In the other si
On 09/22/2015 06:38 AM, Stig Bakken wrote:
Actually, you need to think about compatibility in a bigger perspective.
One of the first things I would want do if PHP were to grow enums, is
to add support for it to Apache Thrift. For those not familiar with
it, Thrift is basically an IDL for specify
Dan Cryer wrote on 22/09/2015 16:06:
C#'s enums seem a good model to follow.
It's worth pointing out that C#'s enums are basically the same as C's -
a typedef over int with a handful of helper methods in the standard
library. They don't even range-check on assignment, so that a "weekday"
var
On Tue, Sep 22, 2015 at 10:29 AM, Rowan Collins wrote:
> Dan Cryer wrote on 22/09/2015 16:06:
>>
>> C#'s enums seem a good model to follow.
>
>
> It's worth pointing out that C#'s enums are basically the same as C's - a
> typedef over int with a handful of helper methods in the standard library.
>
Am 22.09.2015 um 12:38 schrieb Stig Bakken:
> The point I'm trying to make is that an enum's normalized
> representation should be an integer, and that is also how it should be
> serialized.
Makes sense to me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
>
> You can always serialize things however you want. Using `serialize()`
> is just a convenience – there is absolutely nothing that prevents you
> from using a custom serialization routine. Note that while Java has
> built in serialization it is often not used, and instead libraries
> like Google'
> The point I'm trying to make is that an enum's normalized
> representation should be an integer, and that is also how it should be
> serialized. It also happens to be how most other languages chose to
> represent enums, and deviating from that will cause all kinds of pain
> the minute you need to
On Fri, Sep 18, 2015 at 2:05 AM, Rowan Collins wrote:
> On 18/09/2015 00:34, user@domain.invalid wrote:
>>
>> Well, how are you supposed to serialize an enum value without some sort of
>> numerical representation or value? Maybe you could serialize it by
>> converting the enum to a string represen
On 18 September 2015 03:58:57 BST, Stephen Coakley
wrote:
>On 09/17/2015 06:06 PM, Rowan Collins wrote:
>> member THURSDAY, FRIDAY, SATURDAY, SUNDAY; // don't force people
>to
>> write each entry on its own line; maybe even the "member" keyword is
>too
>> much?
>
>Member is even a little too
Jefferson Gonzalez wrote on 18/09/2015 03:20:
On 09/17/2015 08:05 PM, Rowan Collins wrote:
I don't think serializing to a name is particularly more inefficient
than serializing to an integer - depending on the internal
implementation, of course. Or do you mean efficiency in terms of the
length o
On 09/17/2015 06:06 PM, Rowan Collins wrote:
Hi All,
This has come up in passing a few times recently, but I'm not sure
there's ever been a dedicated discussion of it: would it be useful for
PHP to have a built-in Enumeration type, and if so, how should it look?
Many other languages have enum t
On 09/17/2015 08:05 PM, Rowan Collins wrote:
I don't think serializing to a name is particularly more inefficient
than serializing to an integer - depending on the internal
implementation, of course. Or do you mean efficiency in terms of the
length of the string produced?
Exactly! Lets say you
On 18/09/2015 00:34, user@domain.invalid wrote:
Well, how are you supposed to serialize an enum value without some
sort of numerical representation or value? Maybe you could serialize
it by
converting the enum to a string representation of its name but that
wouldn't be efficient and also if a d
On 09/17/2015 07:06 PM, Rowan Collins wrote:
3) there should be no accessible "value" for a member; the value of
Weekdays::SUNDAY is simply Weekdays::SUNDAY, not 0 or 7 or 'SUNDAY' (I'm
thinking that internally, each member would be represented as an object
pointer, so there's no real benefit to
15 matches
Mail list logo
