Template help - MultiAccess

[Era Scarecrow]

On Tuesday, 8 January 2013 at 23:17:46 UTC, Philippe Sigaud wrote:
> On Tue, Jan 8, 2013 at 10:37 PM, Era Scarecrow wrote:
> Some comments:
>
> mixin(multiAccess!(
>                 int,        //return type
>                 "test",     //function call/name
>                 "nothrow",  //attributes
>                 choice,     //variable/call that determines 
> which to call
>                 true,       //make read function
>                 true,       //make write function
>                 a, false,   //choose a if 'choice' is false
>                 b, true));  //choose b if 'choice' is true
>
> The 'int,' part is not necessary: names a and b have a type, 
> you can determine int from CommonType!(typeof(a),typeof(b)).
> One less field for your user.

  Maybe not. In other use cases the variables may be in quoted 
allowing you to specify it's within other structs (or functions), 
same with the 'choice'. I'm currently working on modifying my 
code to do that very thing, so a return type may very well still 
be required.

> Concerning the 'true'/'false' parts for the read/write 
> function: I'm not sure they are necessary. If you want your 
> host to be a multi access struct, you sure want people to 
> access the fields...

> Should you still choose to let these parameters, please use two 
> enums:
> enum ReadAccess { no, yes } and WriteAccess { no, yes }.
> This makes for a more explicit code when calling the template:

  True, and most likely I will move to enums, but I needed a quick 
and easy way to tell them apart; I'm sure there's cases where you 
only want to write or read from particular variables (empty for 
example?).

  I'd probably condense it into a single enum, being something 
like: enum Access { read, write, readWrite }.

> For the (a, true) pairs, I'd invert the arguments: first the 
> value, then the effect (in this case, which field to access).

  If it makes more sense to do so then I have no objection. More 
likely they'll be ints or enums. in my more complex unittest it 
uses:
   a, 0,
   b, 1,
   c, 2

  so would this look better?
   0, a,
   1, b,
   2, c

  Somehow seems backwards to me, I almost think of them more as 
a=0, b=1, c=2 type of thing; vs 0=a, 1=b, 2=c, but with enums 
then a=one, b=two, c=three vs one=a, two=b, three=c; both look 
kinda natural.

> As for the global usefulness of your mixin, I don't know. I 
> never felt a need for such a construction, so I can't comment 
> much more on it.

  Global use is very unlikely (but not impossible) as that type of 
access seems to be shunned from the bad code it generated. Much 
less so now. The only problem with making it global is the 
reading function having const, as the compiler complains about 
requiring 'this'.