> As long as you expose OS cruft, your wrappers are useless, I'm
afraid.
> I suggest you to provide safe and meaningful wrappers, e.g.
streams, ranges, for concrete business cases which deal with OS directly so that the wrapper won't need flags from user (they are usually encoded in the function name) and know all necessary flags for OS call. Some flags are even win9x legacy and new code should not use them and request only needed access. For example, generic* and maximum* flags are usually never needed and their use is discouraged.


Thanks for the advice, but I wasn't asking about whether my wrappers are useful (they're certainly useful for myself, and that's enough reason for me to make them).

I was asking about how to avoid redundancy in enums (it's not like they don't have uses other than access masks...), and this didn't answer the question.

"%u" <wfunction@hotmail.com> wrote in message news:ik7slf$2q2u$1@digitalmars.com...
>> What exactly is it that you're trying to do?
>
>
>>> (1) I'm not going to create a new instance of an entire class
> every single time I need to check an access mask, that's wasteful.
>> I meant, you write File.open or File.isReadable which do the job
> for you and don't expose OS cruft.
>
>
> That's what I'm doing! I'm precisely trying to wrap the Windows NT API, and so I'm making classes like NtObject, NtFile, NtToken, etc., to wrap functions like NtOpenFile, NtQueryObject, etc. (I'm aware that some of them are undocumented, but I live with that.)
>
> So I have different kinds of access masks:
> 1. Generic access masks that can be passed to _any_ procedure and
> combined with any other access masks, like GENERIC_READ,
> MAXIMUM_ALLOWED, etc.
> 2. Object-specific access masks that can be only used for specific
> objects and that can be combined with each other and with generic
> access masks, like FILE_READ_DATA, TOKEN_ALL_ACCESS, etc.
>
> So I'm trying to avoid redundant code here, because any member of an AccessMask enumeration would also be inside the FileAccess enum, the TokenAccess enum, the ThreadAccess enum, etc. But at the same time, I need to be able to pass both specific and generic access masks to functions that take in specific access masks.
>
> So the question is, what's the best way to do it?

I know some people don't like using mixins, but I think that's really the best way to achieve that effect without loosing DIY and without resorting to something more heavy-weight:

void funcA(A a) {}
void funcB(B b) {}

enum stdAccess = q{
    STD_ELEMENT_1 = 17,
    STD_ELEMENT_2 = 42,
};

enum A {
    mixin(stdAccess);
    A_ACCESS_1 = 0x80,
}

enum B {
    mixin(stdAccess);
    B_ACCESS_1 = 0x80,
}

Or, if you really don't want mixins, or if you really want STD_ELEMENT_1/etc... to always be of one single type, then make the std ones their own distict type and use either function overloading or algebraic types:

enum STD {
    STD_ELEMENT_1 = 17,
    STD_ELEMENT_2 = 42,
}

enum A {
    A_ACCESS_1 = 0x80,
}

enum B {
    B_ACCESS_1 = 0x80,
}

void funcA(A a) {}
void funcA(STD a) {}
void funcB(B b) {}
void funcB(STD b) {}
// Or:
void funcA(Algebraic!(A,STD) a) {}
void funcB(Algebraic!(B,STD) b) {}

I think your main original problem was that there isn't really a way to compose enums additively, only subtractive.

Although, maybe you could experiment with something like:

    enum X : Algebraic!(...) {}

Not sure if that would help get what you want, though, or if it would even work at all.

"Nick Sabalausky" <a@a.a> wrote in message news:ikcepj$248p$1@digitalmars.com...
>
> I think your main original problem was that there isn't really a way to compose enums additively, only subtractive.
>

That just gave me an idea: I think you should be able to get away with an ordinary union:

enum STD {
    STD_ELEMENT_1 = 17,
    STD_ELEMENT_2 = 42,
}

enum AOnly {
    A_ACCESS_1 = 0x80,
}

enum BOnly {
    B_ACCESS_1 = 0x80,
}

union A {
    STD std;
    A a;
}

union B {
    STD std;
    B b;
}

void funcA(A a) {
    if(a.a == A_ACCESS_1) {}
    if(a.std == STD_ELEMENT_1) {}
}

void funcB(B b) {
    if(b.b == B_ACCESS_1) {}
    if(b.std == STD_ELEMENT_1) {}
}

In the general case, I'd be very hesitent to use a non-tagged union like this, because it wouldn't provide protection against accidentally having the same integer value for a member of STD and a member of A or B (which would obviously screw the whole thing up). But in your paricular case it doesn't seem that would likely be an issue.

Of course, if you dodn't mind a heavier-weight OO-based solution, you could always use classes instead of enums and use static immutable class members as the possible values (and make the constructor private to prevent additional possible values), but personally I think that would be over-engineered compared to either the above or the mixin solution in my previous message.

> I know some people don't like using mixins, but I think that's
really the best way to achieve that effect without loosing DIY and without resorting to something more heavy-weight
> ...
> That just gave me an idea: I think you should be able to get away
with an ordinary union

I thought about those, but ultimately, the problem is that they're not extensible: if a new type of access mask is introduced. In the former case, I can't AND it with a generic access mask to test what the result is, because they're of different types; in the latter case, there's no way to extend this whatsoever. :\

I'm trying to keep this extensible while avoiding code duplication, and it's proven to be surprisingly hard to do this neatly.

Actually, on a second thought, I just noticed that the union method *is* extensible, since you're putting things in different unions... I think I'll give it a shot, thanks! :)

On 02/27/2011 04:20 AM, Nick Sabalausky wrote:
> "Nick Sabalausky"<a@a.a>  wrote in message
> news:ikcepj$248p$1@digitalmars.com...
>>
>> I think your main original problem was that there isn't really a way to
>> compose enums additively, only subtractive.
>>
>
> That just gave me an idea: I think you should be able to get away with an
> ordinary union:
>
> enum STD {
>      STD_ELEMENT_1 = 17,
>      STD_ELEMENT_2 = 42,
> }
>
> enum AOnly {
>      A_ACCESS_1 = 0x80,
> }
>
> enum BOnly {
>      B_ACCESS_1 = 0x80,
> }
>
> union A {
>      STD std;
>      A a;
> }
>
> union B {
>      STD std;
>      B b;
> }
>
> void funcA(A a) {
>      if(a.a == A_ACCESS_1) {}
>      if(a.std == STD_ELEMENT_1) {}
> }
>
> void funcB(B b) {
>      if(b.b == B_ACCESS_1) {}
>      if(b.std == STD_ELEMENT_1) {}
> }
>
> In the general case, I'd be very hesitent to use a non-tagged union like
> this, because it wouldn't provide protection against accidentally having the
> same integer value for a member of STD and a member of A or B (which would
> obviously screw the whole thing up). But in your paricular case it doesn't
> seem that would likely be an issue.
>
> Of course, if you dodn't mind a heavier-weight OO-based solution, you could
> always use classes instead of enums and use static immutable class members
> as the possible values (and make the constructor private to prevent
> additional possible values), but personally I think that would be
> over-engineered compared to either the above or the mixin solution in my
> previous message.

Very interesting solution, indeed: enum composition via union. I think as well it's safe because --per definition-- each 'code' of a discriminating enum must have a distinct value. (They are nominals: http://en.wikipedia.org/wiki/Nominal_number).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/27/2011 07:21 AM, %u wrote:
> Actually, on a second thought, I just noticed that the union method
> *is* extensible, since you're putting things in different unions... I
> think I'll give it a shot, thanks! :)

And you can always "super-compose" unions. This view, in fact, is similar to the (famous) OO debate upon composition vs inheritance; but at lower level.
http://en.wikipedia.org/wiki/Composition_over_inheritance

Denis
-- 
_________________
vita es estrany
spir.wikidot.com