Frits van Bommel 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?
Polymorphic. Then of course there's the Finalize!(C) template that takes
a class C and makes all of its methods final. Compile-time introspection
is a treasure trove.
Would it also delegate template methods?
Good question. I don't know how template methods could be handled.
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))?
I don't know. We need more experience to figure that out.
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?
Segfault :o).
Andrei
