www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Annoyances with traits

reply "F i L" <witte2008 gmail.com> writes:
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.
Mar 27 2012
next sibling parent Manu <turkeyman gmail.com> writes:
On 28 March 2012 07:29, F i L <witte2008 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.
Mar 28 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 28 Mar 2012 06:29:30 +0200
schrieb "F i L" <witte2008 gmail.com>:


 I find myself using __traits(hasMember, T, "member") a lot.
 It's really basic feature of meta-programming.
 


We already had this discussion 3 years ago, there's even a bug report:

http://d.puremagic.com/issues/show_bug.cgi?id=3702
http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html

And related:
http://forum.dlang.org/thread/in00fa$4fa$1 digitalmars.com?page=1

I think someone just has to implement that 'meta' namespace and start a
pull request, I doubt there will be a big resistance against it.
Mar 28 2012
prev sibling next sibling parent reply "RivenTheMage" <riven-mage id.ru> writes:
My proposal:
http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html
Mar 28 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 28 March 2012 20:01, RivenTheMage <riven-mage id.ru> wrote:


 My proposal:
 http://www.digitalmars.com/d/**archives/digitalmars/D/Yet_**
 another_compile-time_**reflection_revisited_proposal_**150309.html<http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html>



Yes please! :)
Although I'm not sure why you distinguish 'metainfo' from 'meta'?

These proposals all look basically the same, more or less.
I'm curious to know why it wasn't done that way in the first place? It
seems the obvious approach...
Mar 28 2012
parent "RivenTheMage" <riven-mage id.ru> writes:
On Wednesday, 28 March 2012 at 22:23:51 UTC, Manu wrote:


 Although I'm not sure why you distinguish 'metainfo' from 
 'meta'?


To me, it's consistent with .typeinfo and .classinfo properties.
Mar 28 2012
prev sibling parent "F i L" <witte2008 gmail.com> writes:
On Wednesday, 28 March 2012 at 17:01:50 UTC, RivenTheMage wrote:

 My proposal:
 http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html


I like this idea more than the one I purposed.
Mar 28 2012
prev sibling parent reply "F i L" <witte2008 gmail.com> writes:
I'd like to add to what I suggested earlier. Conversion between
types is a common and expected behavior. Because std.conv is
small, and the new UFCS is here, I think object.d could benefit.
Hear what I had in mind:

+ Move std.conv functionality to object.d
+ Move Object.toString() from the base class, to free space.
+ Make toString() simply wrap to!string() and depreciate it.
+ Replace parse!() with a more intelligent to!()/string

+ emplace!() would be handy to always have around :)
+ idk what to do with text!() :/

Now we can convert types as a language feature, and toString()
still works, but universally on any type that defines opCall().
Also, like I said, toString() might just wrap to!string() and be
marked as depreciated (since we already have .stringof).

      auto name = "Jacque Fresco";
      auto age = 96;

      writeln("Hi, I'm ", name, ".");
      writeln("I'm ", age.text(), " years old");
      writeln("This shit's got to go!"); // ;)

      writeln("How old are you?");

      auto line = readln();
      auto theirAge = line.to!int();
Mar 29 2012
parent reply Manu <turkeyman gmail.com> writes:
On 29 March 2012 20:07, F i L <witte2008 gmail.com> wrote:


     auto name = "Jacque Fresco";
     auto age = 96;

     writeln("Hi, I'm ", name, ".");
     writeln("I'm ", age.text(), " years old");
     writeln("This shit's got to go!"); // ;)


Hah!
Nicely played ;)
Mar 29 2012
parent "F i L" <witte2008 gmail.com> writes:
On Thursday, 29 March 2012 at 21:29:04 UTC, Manu wrote:

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


     auto name = "Jacque Fresco";
     auto age = 96;

     writeln("Hi, I'm ", name, ".");
     writeln("I'm ", age.text(), " years old");
     writeln("This shit's got to go!"); // ;)


 Hah!
 Nicely played ;)


XD

I was hoping someone would get that reference.
Mar 29 2012