On Friday, 21 March 2014 at 09:54:24 UTC, Chris wrote:
On Thursday, 20 March 2014 at 20:20:28 UTC, John Colvin wrote:
On Thursday, 20 March 2014 at 19:38:25 UTC, Chris wrote:
On Thursday, 20 March 2014 at 18:54:30 UTC, John Colvin wrote:
On Thursday, 20 March 2014 at 18:39:32 UTC, Chris wrote:
On Thursday, 20 March 2014 at 17:49:52 UTC, John Colvin
wrote:
On Thursday, 20 March 2014 at 16:40:50 UTC, Chris wrote:
On Thursday, 20 March 2014 at 16:32:34 UTC, Vladimir
Panteleev wrote:
On Thursday, 20 March 2014 at 16:28:46 UTC, Chris wrote:
How can I instantiate Person with Trait, i.e. a
template with a template?
struct Trait(T0, T1) {
T0 name;
T1 value;
T1[T0] map;
this(T0 name, T1 value) {
this.name = name;
this.value = value;
map[name] = value;
}
}
class Person(T) {
T traits[];
void addTrait(T trait) {
traits ~= trait;
}
}
void main()
{
auto trait1 = Trait!(string, string)("Name", "John");
auto trait2 = Trait!(string, int)("Age", 42);
writefln(%s", trait1.map);
writefln(%s", trait2.map);
// above code compiles and works
}
Person!(Trait!(string, string)) person;
-- or --
alias MyTrait = Trait!(string, string);
Person!MyTrait person;
Note that this approach won't let you have traits with
different parameters within the same Person type.
Yep, I've already tried this (sorry I should've mentioned
it!). But I don't want this restriction.
Arrays are homogeneous. All the elements must be of the
same type. Different instantiations of templates are
different types.
You could use an array of std.variant.Variant
The elements are all of type Trait. However, Type itself
might be
of different types. That's why it is not possible? I've come
across this restriction before when using templates, which
is a
big disappointment because it restricts the
"templatization" /
generalization of data structures somewhat.
Trait is not a type. Trait is a template. An instantiation
of the Trait template is a type.
Arrays are contiguous, homogeneous data. This is fundamental
to their design and their performance characteristics.
Workarounds use at least one of the following: indirection,
tagging* and padding. Variant uses tagging and padding.
Interface/base-class arrays use indirection (and tagging,
ultimately).
*inline or external, or even compile-time.
This is true in *every* programming language, just with
different names.
I thought the array T[] traits could hold any _type_ the
template Trait is instantiated into. That's where I got it
wrong. I understand the practical aspects of this restriction
(homogeneous data, performance and the work around involved
etc.). However, this makes templates less universal and
rather cumbersome to work with in certain circumstances. Take
for example the Person class. If I want to do numerical
operations with the age of the person, I will have to convert
the age to an int (or whatever) later on instead of just
doing it once at the beginning (when loading data). So
everytime I access Trait.map["age"] I will have to convert it
to a number before I can calculate anything. This, or I store
it in a field of its own when instantiating Trait. Whatever
workaround I choose it will make it less elegant and less
simple.
Maybe I expect(ed) to much of templates. Mea culpa.
Try this:
import std.stdio;
import std.variant;
enum maxTraitSize = 64;
struct Trait(T0, T1)
{
T0 name;
T1 value;
T1[T0] map;
static assert(T0.sizeof + T1.sizeof + (T1[T0]).sizeof <=
maxTraitSize);
this(T0 name, T1 value)
{
this.name = name;
this.value = value;
map[name] = value;
}
}
class Person
{
alias ElT = VariantN!maxTraitSize;
ElT[] traits;
void addTrait(T)(T trait)
if(is(T == Trait!Q, Q...))
{
traits ~= ElT(trait);
}
}
void main()
{
auto trait1 = Trait!(string, string)("Name", "John");
auto trait2 = Trait!(string, int)("Age", 42);
writefln("%s", trait1.map);
writefln("%s", trait2.map);
auto p = new Person;
p.addTrait(trait1);
p.addTrait(trait2);
writeln(p.traits);
}
Thanks John, this does what I had in mind. I don't know,
though, if I will use it for a real world application. I would
have to test the behavior thoroughly first. The background is
that I will have variable user input, i.e. users
(non-programmers) define traits and rules. There is no way to
foresee what names users will choose. That's why Trait stores
arbitrary keys and values (and Meta's solution is not an
option). I only thought it would be nice to have [string:int]
straight away for numerical operations further down the road. I
was also thinking about using std.variant. But I'm just
starting out with this ...
Btw, I was initially inspired by Objective-C's NSSet that can
hold arbitrary objects.
