Annoyances with traits

[Manu]

On 28 March 2012 07:29, F i L <witte2008 at gmail.com> wrote:

> I find myself using __traits(hasMember, T, "member") a lot.
> It's really basic feature of meta-programming.
>
> I'm not a fan of the "__usedByCompiler" syntax, but that's a
> whole different discussion. __traits() is fine (besides the fact
> that first-argument-as-function is syntactically inconsistent to
> the rest of the language), but std.traits doesn't wrap it
> correctly; and, because it's globally available anyways & so
> often used, shouldn't have to be imported to use in the first
> place, IMO.
>
> What I would like to see happen: Have a traits.d which replaces
> std.traits and is always included (like object.d) which properly
> wraps __trait functions.
>
> so in traits.d:
>
>     // use alias T, so we can pass "laser.x" to it
>     // without having to pass typeof(laser.x). Just like
>     // we can with using __traits(hasMember, ...)
>
>     template hasMember(alias T, string member) {
>         enum hasMember = __traits(hasMember, T, member);
>     }
>
> we can then write:
>
>     auto laser = ship.fire();
>     static if(traits.hasMember!(laser.x, "isProp") ...;
>
> which feels syntactically consistent. Because traits are in their
> own module, we could emit the "traits." and just call
> "hasMember()". Even better, if UFCS allows, we could simply write:
>
>     static if(laser.x.hasMember!("isProp"**)) ...;
>
>
> my 2 cents.
>

I was rummaging through exactly the same stuff yesterday, and reached a
similar conclusion.
My code became borderline impossible to understand very fast with all the
references to __traits(getMember, instanceOf, member) and friends.
Something like you suggest would go a long way to making it readable again.

One thing I noticed recurring, __traits(getMember, T, member) can be
aliased, but __traits(getMember, instanceOfT, member) can not really be
aliased, since D doesn't have references. Is there a practical way to do
this? Granted, it's not so necessary if the syntax to do that wasn't so
long and cumbersome.

The other thing I found was within a few functions I was desperately
wanting user attributes. I was interacting with a database, and without
being able to attribute row structure items, it's very messy and hacky to
specify which item was the primary key, which items should be relational
references, mask items which should be ignored, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120328/eff4cd92/attachment.html>