Style question

Maxim Fomin maxim at maxim-fomin.ru
Thu Jul 11 22:57:19 PDT 2013


On Thursday, 11 July 2013 at 20:15:52 UTC, Namespace wrote:
>> The whole situation looks strange. If you can change both 
>> files, than it is unclear what made you to write such 
>> inconsistent code. If you can change only one of them, then it 
>> should be adjusted to another (meaning importing external file 
>> and using that enum instead of trying to define different type 
>> and passing it).
>
> Besides the problem of changing existing API:
> If you change only one of those modules and use the enum from 
> the other file, every user have to look into the file which 
> declares the enum, to see which member the enum has.

This argument can be applied to virtually any peice of code of
any language which has import or #include.

>> This is almost same as direct cast in #2. Instead of making 
>> test2() accept B or (u)int consider making it static void 
>> test2 (MyClass.A a) and wipe out enum B entirely.
>
> That's the problem I tried to describe above.
> If you have those two modules as in my example code, the one 
> file without the enum depends on the one with the enum. Isn't 
> that a bad situation?

Any file importing map depens on std.algorithm. Isn't that a bad
situation?

> A possible solution would be to change one of those functions 
> which accepts different enums, that it accept an uint - nothing 
> else is an enum (in this case).

Well if you consider that this is a best option nothing stops you
from doing this. In such case you can't mark functions as @safe
and may run into bugs when some integer value placed into enum
does not fit into allowed values. This problem is tackled by
final switches. By the way, in your case base type is int, not
uint.


More information about the Digitalmars-d-learn mailing list