make Enum can get size or have a iterator

[PhoenixZeng]

sometimes i want to know how much eles in the enum and want to make a iterator if the enum can get size (Gets the number of fields in the enumeration) we can use for-to to iteration a enum

for i = 0 to a_enum.size -1 
    let a = i castTo a_enum

i can make a std-iterator for a enum . but i want have a easy way to iteration all enum

it is easy to realize ,i think

[peq]

Thanks for the suggestion. Seems like a useful extension to the language.

[peq]

See also: https://github.com/wurstscript/WurstScript/issues/433

[PhoenixZeng]

yes. Get name of a value as string is good i make it by my self now

[PhoenixZeng]

why the enum cant be impl like the java enum. (We can let the enumerator have a default _index field to be compatible with the existing enumeration.) eg:

enum level_price
   a(100) // always use the all args construct func
   b(200)
   c(300) // use the indent to write field and func
        // _index is the Reserved field
       int cost
       function c() returns int
            return this.cost
init
   print( level_price.size()) //3
   print(  level_price.a castTo int) // 0
   print(  level_price.a.toString()) // "a"
   print(  level_price.a.cost) // 100
   print(  level_price.a.c()  ) // 100

just like:

class level_price
   int _index
   int cost
   static a = new level_price(0,100)
   private construct(int _index,int cost)
      this._index = _index
      ......

Such enumeration can continue to retain his integer features, and it can also have more powerful functions.

[Frotty]

They could, but it would require a pretty much complete rewrite of their implementation. Because in Java, enums are basically static instances of a class. In wurst however, the members of an enum are translated directly into constant integers. The enum itself doesn't even exist in the generated code and the "class-like" behaviour is only possible via extension functions and due to the type existing at compiletime, but not runtime. This makes it harder to add additional class behavior or features that rely on such meta data/type persistence.

[PhoenixZeng]

@Frotty So,A simple solution for this issues title the compiler always think enum have 2 function size(),name()/toString() should be useful and easy impl (Of course they can be override)

Optional ： the "class-like" field can replace by extension functions (getXXX()) with switch block when compile. the:

enum level_price
   a(100) // always use the all args construct func
   b(200) //args should be const
   c(300) // use the indent to write field and func
        // _index is the Reserved field
       int cost
       function c() returns int
            return this.cost

will be replace to

enum level_price
   a
   b
   c
function level_price.getCost() returns int
      switch .....
function level_price.c() returns int
     //when anyone get the enum field . use getXXX() replace it
     return this.getCost()

and compiler compile it Just like now. enum can have not the meta data/type persistence

[Frotty]

The answer was directed at "why the enum cant be impl like the java enum." Something like your ideas might sound simple, but it actually requires syntax and fundamental changes plus additional validation, because enums aren't designed to have any attributes right now.

[peq]

I don't like the concept of enum parameters as Java has them. It really does not add much value compared to a normal function definition.

My long term plan for the language is to have algebraic data types, which would support the use cases of current tuple types and of current enum types.

Something like enums in Rust:

https://doc.rust-lang.org/rust-by-example/custom_types/enum.html https://doc.rust-lang.org/book/second-edition/ch06-01-defining-an-enum.html

So yes, enum parameters might come eventually, but it's more likely they will work like in Rust and not like in Java.

[Frotty]

So yes, enum parameters might come eventually, but it's more likely they will work like in Rust and not like in Java.

Since this will likely take a long time I can see myself implementing at least the reflection stuff from #433 before that