JS:
It would be nice to be able to use enums in a hierarchical way:
enum colors
{
enum Red { RedOrange, ... }
enum Green { GreenBlue, ...}
enum Blue { BlueYellow, ... }
...
}
which would be the same as the flattened version,
enum colors
{
Red, RedOrange, ..., Green, GreenBlu
On Monday, 15 July 2013 at 19:24:27 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 18:26:26 UTC, JS wrote:
Original I had it as a class. I'm not sure if it matters much
between a class and a struct though?
It does matter a lot. structs are value types, classes are
polymorphic reference types.
On Monday, 15 July 2013 at 18:26:26 UTC, JS wrote:
Original I had it as a class. I'm not sure if it matters much
between a class and a struct though?
It does matter a lot. structs are value types, classes are
polymorphic reference types. There is a nice summary table in
docs: http://dlang.org
On Monday, 15 July 2013 at 13:47:10 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 13:01:05 UTC, JS wrote:
...
I see. No, unfortunately, I am currently not aware of a way to
make symbol act as type and and value at the same time.
However it is worth noting that you use plenty of excessive
On Monday, 15 July 2013 at 13:01:05 UTC, JS wrote:
...
I see. No, unfortunately, I am currently not aware of a way to
make symbol act as type and and value at the same time.
However it is worth noting that you use plenty of excessive
attributes. Currently it is not a compiler error but make
On Monday, 15 July 2013 at 11:00:59 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 04:24:59 UTC, JS wrote:
...
I think closest solution you can get is having bunch of private
enum definitions and combining them into single public one via
compile-time reflection. Something like
"mixin(genera
On Monday, 15 July 2013 at 10:23:22 UTC, JS wrote:
On Monday, 15 July 2013 at 10:17:08 UTC, JS wrote:
On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue {
On Monday, 15 July 2013 at 04:24:59 UTC, JS wrote:
...
I think closest solution you can get is having bunch of private
enum definitions and combining them into single public one via
compile-time reflection. Something like "mixin(generateEnum!(Red,
Green, blue))".
On Monday, 15 July 2013 at 10:17:08 UTC, JS wrote:
On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo
On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo = Colors.Red.RedOrange;
assert(foo >= Color
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo = Colors.Red.RedOrange;
assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
}
On Monday, 15 July 2013 at 07:37:36 UTC, Mike Parker wrote:
On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
BTW, the usefulness is to group sub-enums into the same range.
This would make it easy/efficient to branch over a range in
the enum:
if (v in colors.Red) { v is a color in red }
ins
On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
BTW, the usefulness is to group sub-enums into the same range.
This would make it easy/efficient to branch over a range in the
enum:
if (v in colors.Red) { v is a color in red }
instead of
if (v is color.Red || v is color.RedOrange || ...)
On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
BTW, the usefulness is to group sub-enums into the same range.
This would make it easy/efficient to branch over a range in the
enum:
if (v in colors.Red) { v is a color in red }
instead of
if (v is color.Red || v is color.RedOrange || ...)
BTW, the usefulness is to group sub-enums into the same range.
This would make it easy/efficient to branch over a range in the
enum:
if (v in colors.Red) { v is a color in red }
instead of
if (v is color.Red || v is color.RedOrange || ...)
It would be nice to be able to use enums in a hierarchical way:
enum colors
{
enum Red { RedOrange, ... }
enum Green { GreenBlue, ...}
enum Blue { BlueYellow, ... }
...
}
which would be the same as the flattened version,
enum colors
{
Red, RedOrange, ..., Green, GreenBlue, ...
On 8/13/11 9:42 PM, Simen Kjaeraas wrote:
On Sun, 14 Aug 2011 01:15:29 +0200, mimocrocodil <[email protected]>
wrote:
Hi!
I am want to extend available enum to provide more items to them.
How I can do this job without manual copying of exsisting enum items?
If what you want is a new enum t
On Sun, 14 Aug 2011 01:15:29 +0200, mimocrocodil <[email protected]>
wrote:
Hi!
I am want to extend available enum to provide more items to them.
How I can do this job without manual copying of exsisting enum items?
If what you want is a new enum that contains the values of an existing
On Saturday, August 13, 2011 23:15:29 mimocrocodil wrote:
> Hi!
>
> I am want to extend available enum to provide more items to them.
>
> How I can do this job without manual copying of exsisting enum items?
You can't. An enum has a fixed set of values. You can't extend it in any way,
shape, or
Hi!
I am want to extend available enum to provide more items to them.
How I can do this job without manual copying of exsisting enum items?
20 matches
Mail list logo
