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'.
