Dynamic D

[Robert Jacques]

On Thu, 06 Jan 2011 13:24:37 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> 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".

It does, with the enhancement that assignment/initialization can occur by  
'member' assignment. Personally, I think assigning to a void Variant  
should be as permissive as possible, but this behavior is trivial to  
remove if needs be.

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

And JSON is supposed to be implemented _as_ a variant; it's one of the  
major use cases and feature litmus tests. Besides, Variant is supposed to  
"interfacing with scripting languages, and [allow] comfortable exploratory  
programming", and since this facilitates both those design goals of  
variant, I think this is within scope.

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

Except that they don't share _any_ methods. That's the point I was trying  
to make.

> Generally Algebraic with closed hierarchies (e.g. Visitor) are good  
> candidates for the feature.

Since you used 'closed hierarchies' to describe JSON, what exactly do you  
mean by it? 'closed hierarchies' to me implies an inheritance-like  
relationship between, which generally means that Algebraic is the wrong  
choice (i.e. why not use a common interface or super-type?)

[snip]

>>> * 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"?

Because it implements prototype based programming and not dynamic  
programming. (http://en.wikipedia.org/wiki/Prototype_based_programming)

>
> Andrei