Re: enum options
- Posted by CChris Jul 18, 2008
- 910 views
Yes, that was my initial thinking but for the purpose of this example I wanted to keep it simple. The base=N is kinda nice but resetting it could be problematic. For example ...
with enum base = 1 enum foo, bar with enum base = 4 enum qwerty, asdfgh . . . without enum base -- ??? resets to one enum poiuy, trewq
I would reset it to the default of 1.
I'm worried about scope creep for 4.0 though.
Yes, this doesn't have to be in 4.0. I'm just thinking while the subject is alive.
Jeremy
There is a little known include file in win32lib that is called series.e. It implements all of the above and more. Why not simply make it a standard include? No need to ask for a permission.
Doing this would make a difference between builtin enums as were implemented and series. But I don't think it would be terribly difficult to put this code inside the interpreter proper. ?ot in 4.0 alpha, there is some urgency to release something. And there are issues to blend the syntax into known enums. I had tried to push for named enums, but....
How about this?
enum [ ( [from start_value] [to end_value] [by additive_value] | [grow multiply_factor] | [using routine_id] [label "fields"] ) ] foo, bar, ...
The brackets only show optional components, and are not to be written.
The parentheses mark the limits of the option list as opposed to the member list. I'd have nothing against using { } instead. Just some pair of delimiters currently not expected after enum.
In keeping with other labels currently in the language, the enum identifier is a string. However, contrary to current other labels, it may need to hold a valid identifier so as to be able to query properties of the enum. This restriction could be removed if we implement the query as enum_meta("fields", ENUM_FROM). You get the idea.
CChris
