On Mon, 16 Feb 2009 00:20:47 +0300, Frits van Bommel
<fvbom...@remwovexcapss.nl> wrote:
Andrei Alexandrescu wrote:
Spot on. My ambitions are actually a tad higher. I want to implement
containers as by-value structs defining value semantics and the needed
primitives. Then, using introspection, I want to define a template
Class that takes a struct and turns it into a class. For example:
struct SomeContainer(T)
{
ref T opIndex(size_t n) { ... }
}
auto byval = SomeContainer!(int)();
auto javalike = new Class!(SomeContainer!(int));
The type Class!(SomeContainer!(int)) will store a SomeContainer!(int)
object and will define (by using introspection) a method opIndex of
which implementation will do what the struct's method does. The net
effect is as if the programmer sat down with SomeContainer and changed
"struct" to "class". Of course without the code duplication and the
maintenance nightmare :o).
Class should work for primitive types, e.g. Class!(int) should do what
Integer does in Java and so on.
An interesting idea. Would Class!(T) allow polymorphism, or would all
methods be implicitly final?
Would it also delegate template methods?
And what would happen to any T methods accepting or returning T? Would
they keep returning T or would they be replaced by Class!(T)? Or perhaps
both, through overloading?
Same question for types derived from T (e.g. Nullable!(T), or
SomeContainer!(T))?
For instance in the case of a container it would be nice to allow
Class!(LinkedList!(T)).splice!(Class!(LinkedList!(T)) other) if there's
a LinkedList!(T).splice(LinkedList(T) other).
If such unwrapping were done, how would such methods react if the
Class!(LinkedList!(T)) passed into slice() were null?
You can't do that, because splice accepts non-nullable argument :)
