ref?

Max Samukha samukha at voliacable.com.removethis
Sun Feb 15 13:54:16 PST 2009


On Sun, 15 Feb 2009 13:25:24 -0800, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:

>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.

It is, but in this particular case why not inherit from C and make the
derived class final?

>
>> 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



More information about the Digitalmars-d mailing list