Re: [Vala] enum values and scopes

[Jan Hudec <bulb ucw cz>]

On Tue, Jul 13, 2010 at 11:52:29 +0200, andi wrote:
> Hello list!
> When I have an enum like
>
> enum TrackState {
>       PLAYING = 0,
>       PAUSED,
>       STOPPED
> }

You'd never write this in C++ and less so in C, right? You'd have to write:

enum TrackState {
    TRACK_STATE_PLAYING,
    TRACK_STATE_PAUSED,
    TRACK_STATE_STOPPED,
};

> and do the following
> TrackState state = PLAYING;
> I'll get an error, because valac does not search for possible values in
> the scope of TrackState. Instead I have to write 
> TrackState state = TrackState.PLAYING;
>
> To my mind that's not convenient and also not the way c or c++ does it.

It is, however, the way C# and Java do it and they do it for a reason.

The problem is, that when you have more than 2 enums, some of their values
will probably conflict. Because every other enum usually needs NONE, LAST and
similar entries. It's much more readable to have them scoped with the type,
than to have to disambiguate them causing inconsistent naming all over the
place.

> In my real world example TrackState lives in a class called GlobalAccess
> which is in the namespace Xnoise.
>
> So (provided I don't want to import Xnoise into the default namespace) I
> have to write
>
> if (ga.get_track_state() == Xnoise.GlobalAccess.TrackState.PLAYING)
> blabal();
>
> that's really not convenient and the worst part of it isn't even the
> typing but remembering the complete "path" to the final value.

It should be possible to import not only namespaces, but also specific types.
I am not sure importing inner type will work, but that would certainly be
reasonable thing to allow.

> if (ga.get_track_state() == PLAYING)
> would be much more readable, writable and memorizable.
> And when you want to use values from a different scope you can still
> prefix it.
> If I have just requested a feature that has already been discussed a
> thousand times, I'm sorry.

I can imagine a somewhat "dwimmy" feature to support what you want without
actually causing any conflicts, but it would be a bit complicated. The idea
is that when the compiler encounters an unknown symbol and it would know from
the context what type it wants to convert it to (because it's argument to
function or operator of known type), it would look for constant members of
that type. Except, as I say, it's very dwimmy and quite complicated.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>