On Thu, 06 Jan 2011 13:24:37 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
