Dynamic D

[Andrei Alexandrescu]

On 1/6/11 11:52 AM, Robert Jacques wrote:
> And Variant still only holds an object of some preexisting type. What
> you are seeing is simply syntactic sugar for a Variant of type
> Variant[string]. The above lowers down into:
>
> Variant v;
> Variant[string] __temp;
> v = __temp;
> v["a"] = 10;
> assert(v["a"] == 10);
> v["a"] = { writefln("hello, world"); };
> v["a"].call();
> v["a"] = delegate void(string a, int x) { foreach(i;0..x) writeln(i+1,"
> ",a); };
> v["a"].call("potatoes", 3);
>
> The only morph happens because actually making the Variant default type
> be Variant[string], has some issues (GC interaction, hasValue,
> Variant[string].init isn't usable, etc). So I decided that if and only
> if you used an uninitialized Variant as a Variant[string], it would
> 'morph' to a Variant[string].

I think Variant should default to holding "void".

> As for the v.a -> v["a"] syntactic sugar, I have found it very useful in
> the parsing/use of dynamically structured structs, including JSON.

That's great, but (a) that's again outside what Variant is supposed to 
do, and (b) for JSON we're dealing with a closed hierarchy which 
suggests a different design.

>> * Algebraic holds any of a closed set of types. It should define
>> method calls like a.fun(args) if and only if all of its possible types
>> support the call with compatible arguments and return types.
>
> I have considered this, but while this concept looks good on paper, in
> practice it cripples Algebraic. The issue is that the intersections of
> types tend to have no methods/operators in common. For example,
> Algebraic!(int,string) would have no methods nor operators defined.

Algebraic with the fundamental JSON types is a great example because 
they all may share certain methods. Generally Algebraic with closed 
hierarchies (e.g. Visitor) are good candidates for the feature. Of 
course, if that feature affects other functionality we should avoid it. 
It's just "nice to have".

>> * Variant holds any of an unbounded set of types. Reflection may allow
>> us to define v.fun(args) to look up the method name dynamically and
>> issue a runtime error if it doesn't exist (sort of what happens now
>> with operators).
>
> It's not 'may' anymore. Reflection _does_ allow me to define v.fun(args)
> to look up the method name dynamically and issue a runtime error if it
> doesn't exist. eg:
>
> class Foo { real x = 5; }
> auto foo = new Foo;
> Variant a = foo;
> assert(a.x == 5); // perform runtime reflection on 'a' implicitly
> a.__reflect("x",Variant(10)); // or explicitly
> assert(a.__reflect("x") == 10);
>
>> * Dynamic is a malleable type that you get to add state and methods
>> to, just like in Javascript.
>
> And I have stubbed out a Prototype object for just this reason.

Great. Why not call it "Dynamic"?


Andrei