NewsForumsCodeLogsGallerySpecsSearch

enum vars

Monkey Forums/Monkey Programming/enum vars

c.k.(Posted 2012) [#1]
Did some searching but nothing related.

Does monkey have an enum statement, so I don't have to renumber all my vars/constants every time something changes?!

[monkeycode]
enum alpha, beta, chips, delta, epsilon

' alpha = 0
' beta = 1 (alpha+1)
' chips = 2 (beta+1)
' delta = 3 (chips+1)
' etc... (delta+1)
[/monkeycode]

Could enhance like

[monkeycode]
enum from 1 a, b, c
'or
enum a, b, c=4, d, e ' assigning a value starts from that value
[/monkeycode]

Sure would be handy right about now. :-/


ziggy(Posted 2012) [#2]
[monkeycode]
Class MyEnum Abstract
Const ALPHA = 0
Const BETA = 1
Const CHIPS = 2
Const DELTA = 4
End[/monkeycode]Isn't this the same?


c.k.(Posted 2012) [#3]
I don't think so. With 'enum,' I don't have to assign numbers. It's automatic. Here's a realworld example. Here's what I have to do now:

[monkeycode]
Const gmTitle:Int = 1
Const gmLevelSelect:Int = 2
Const gmPlay:Int = 3
Const gmStats:Int = 4
Const gmResults:Int = 5

Const gmOptions:Int = 6
Const gmOptionsChange:Int = 7
Const gmMessage:Int = 8
Const gmGlobalStats:Int = 9

Const bttnID_Play:Int = 10 ' play the game from level select screen
Const bttnID_Title:Int = 11 ' go back to title screen from level select screen or results screen or stats screen
Const bttnID_Stats:Int = 12 ' go to Stats screen from title screen
Const bttnID_LevelSelect:Int = 13 ' go to level select screen from title screen
Const bttnID_NextLevel:Int = 15
Const bttnID_PrevLevel:Int = 16

Const bttnID_OptionsBack:Int = 19
Const bttnID_Options:Int = 20 ' go to options screen from title screen
Const bttnID_OptionsChange:Int = 21
Const bttnID_Global:Int = 22 ' go to Global stats screen from stats screen
Const bttnID_LocalStatsPrev:Int = 23 ' go up in the local stats list
Const bttnID_LocalStatsNext:Int = 24 ' go down in the local stats list
Const bttnID_GlobalStatsUp:Int = 25
Const bttnID_GlobalStatsDown:Int = 26
Const bttnID_GlobalStatsNextPattern:Int = 27
Const bttnID_GlobalStatsPrevPattern:Int = 28
Const bttnID_GlobalStatsNextInterval:Int = 29
Const bttnID_GlobalStatsPrevInterval:Int = 30

Const gmConnectionError:Int = 31

Const bttnID_OptionsUpdate:Int = 32
Const bttnID_StatsClear:Int = 33
[/monkeycode]

See how items for 17 and 18 are missing? That's because I deleted them. But I haven't yet renumbered all Consts below them. What a pain. Is there an easier way to manage interface elements? :-)

Now, imagine I need to add a few screens or buttons. But I want to keep related Consts together, and not have to put new stuff at the bottom. With the above, I have to RENUMBER EVERYTHING BELOW THE INSERTED NEW CONSTS, if I want to maintain some semblance of readability.

With the below, I just have to insert (and can easily remove) items where I like:

[monkeycode]
enum:Int ' game modes
gmTitle,
gmLevelSelect,
gmPlay,
gmStats,
gmResults,
gmOptions,
gmOptionsChange,
gmMessage,
gmGlobalStats

'...etc.
[/monkeycode]

gmTitle would be 0, and gmGlobalStats would be 8, automagically.


c.k.(Posted 2012) [#4]
This works, but is not optimal:

[monkeycode]

Global cEnum:Int = 0

Function enum:Int( i:Int = cEnum )
cEnum = i + 1
Return i
End

'example usage:

Class game Extends App

Field gmTitle:Int = enum()
Field gmLevelSelect:Int = enum()
Field gmPlay:Int = enum()
Field gmStats:Int = enum()
Field gmResults:Int = enum()

End
[/monkeycode]

Unfortunately, they can't be Consts. But, now I can add/remove at will.


Paul - Taiphoz(Posted 2012) [#5]
Can you use reflection to set a constant ?


c.k.(Posted 2012) [#6]
Taiphoz, I have no idea. :-)


slenkar(Posted 2012) [#7]
the buttons should be numbered from 0 to whatever
the gm's should be numbered from 0 to whatever

a button has nothing to do with a 'game mode'

when i make buttons i put them into 'screen' objects so each screen has buttons numbered from 0


c.k.(Posted 2012) [#8]
slenkar, I agree. I can enum() all the buttons, then enum(0) the first mode and enum() the rest of the modes.

It really doesn't matter, because the point is that all bttnIDs should be different and all modeIDs should be different. As long as that's achieved, success! :-)

I'm using fantomEngine, so some of the bttns have to be public fields (as far as I can tell). I don't know if it's different with other libs, or if there's some better way I could be doing it.


Tibit(Posted 2012) [#9]
+1 vote for enums :)

Enums usually also have another (in my opinion) handy feature which is TypeChecking.

So you can use an Enum like a Class for input into a method.

This is amazing for code readability, and even more handy with intellisense.

Enum Cards
ALPHA
BETA
CHIPS
DELTA
End

Function DealCards( type:Cards, bet:int )
...
End

One now knows to check the enum called Cards, instead of having to guess what some Abstract Class was named that contain the intended Constants.

On the other hand I have never been fond of the word "enum". I'd prefer it to be called "option" because myself I only use enums for that purpose.

Option Cards Alpha,Beta,Chips,Delta

Option Cards
Alpha
Beta
Chips = 9
Delta
End

Print Cards.Alpha 'Prints 0
Print Cards.Delta 'Prints 10

'ex: Method call
DealCards( Cards.Delta, coins )

Can you use reflection to set a constant ?
That would be kinda ironic if that is useful Haha! Clever solution tough :)


ziggy(Posted 2012) [#10]
If this ever gets implemented, I vote for bitwise flag friendly numeration, as:

[monkeycode]Enumerator Mything
Value0
Value1
Value2
Value3
Value4
Value5
End[/monkeycode]

Where Valuen = 2^n so we can use this to properly set status flags.

In this sample this whould be:
Value0=0
Value1=1
Value2=2
Value3=4
Value4=8
Value5=16
While it would be cool, I do not really see it as something *very* important to be added. I would prefer to see Monkey development focused on other areas first.


Samah(Posted 2012) [#11]
If you want to expand "Enum" it should probably be "Enumeration" because "Enumerator" implies that it has some kind of inherent functionality like an abstract "enumerate" method.

I'm fine with "Enum" because it's less typing :-)

Also, using bitwise values will break once you hit 32 options.


c.k.(Posted 2012) [#12]
I use a programming language called Euphoria. Here's how enum gets done: http://openeuphoria.org/docs/lang_decl.html#_120_enum

Notice the DELTA option, which would handle bitwise flags building.


Beaker(Posted 2013) [#13]
I'd really like enums that use the target languages real enum setup. So something like this:
Enumerator Volume : Int
    Low = 1
    Medium
    High
End

..becomes (in c#)..
public enum Volume : int
{
    Low = 1,
    Medium,
    High
}


but more specifically so you can Extern an existing librarys enums.


Rushino(Posted 2013) [#14]
To be honest i find enums to be restrictive. I prefer to work with const. It still have the same benefits otherwise you starting to get problems when it come to serialize the data.


Beaker(Posted 2013) [#15]
Currently I'm having to resort to doing Extern enums like this:
Extern

Class KeyboardType = "KeyboardType"
    Global Standard:KeyboardType
    Global Email:KeyboardType
    Global Url:KeyboardType
    ..etc..
End


Which works pretty well, but it's a horrible kludge.


Gerry Quinn(Posted 2013) [#16]
Enums and constants both cause their own nuisances when you change stuff, IMO.

I'm not sure it matters too much which we have.