Archived

This forum has been archived. Please start a new discussion on GitHub.

Class-Scoped Enums

Hi,

I'd like to see Slice support class-scoped enums:

class foo {
enum Fruit { Apple, Pear, Orange };
};

I'm not sure if this is a problem for some of the mappings, however.

Thanks!

-- Andrew Bell
andrew.bell.ia@gmail.com

Comments

  • Please have a look at this post regarding our new support policy.

    As a general rule, Slice does not allow nested type definitions, to avoid various problems with language mappings. I also don't see any advantage of having such nested types. While for implementation languages, such types can be helpful (for hiding types private to classes), I don't see how an interface definition would benefit from this.
  • Hi,

    If the answer is that there are problems with language mappings, then so be it. On the other hand, I don't understand why it is useful to occasionally scope these things at a lower level in an implementation, but not in the interface. For example:

    module Vehicles {

    class Car {
    enum Color { RED, BLUE, YELLOW };
    };

    class Bus {
    enum Color { RED, WHITE, GREEN };
    };
    };

    Is it unreasonable to want to reuse the name "RED"? Not to me.

    Anyway, in our case we are using freeze and in some cases the slice objects are only server side. It is cleaner for us to limit the scope of the enums to the lowest applicable scope. We may stick other things in the namespace created by the module, and the ability to change the scope can be useful.

    It's not a big deal, I just thought it might be a useful extension that would be simple to implement.

    Thanks,

    -- Andrew Bell
    Iowa State University - Center For Survey Statistics and Methodology
    andrew.bell.ia@gmail.com
  • Enums are a somewhat unfortunate example, because Slice enums had to inherit the brain-dead enum scoping rules from C/C++, otherwise the C++ mapping would have been very ugly. Without these silly scoping rules, you could simply define CarColor and BusColor, and use RED in both of them, without any name clashes.

    In the end, it is a trade-off. We decided to not allow nested enums because we don't allow any other nested types, so to make an exception for enums would be inconsistent. The reason why we don't allow other nested types is simplicity: It would be hard to map to certain languages, and it would also make the slice compilers more complex (see CORBA). Furthermore, as I wrote before, I do not believe that nested types would provide any significant benefit for interface definitions, except perhaps for enums, because of the scoping rules.