Objective-D, reflective programming, dynamic typing

[Andrei Alexandrescu]

Christopher Wright wrote:
> Your Variant can be extended more easily than mine. Your Variant is 
> faster than mine. But yours cannot be used everywhere, and mine can.

But this may be an artificial constraint. For example, you may say "my 
variant can be used with old-style variadics". Phobos' doesn't, but I 
don't think that's important.

Here's where I think std.variant is limited:

1. In interfacing with equally general variants implemented 
independently. I know it sounds a bit cryptic, but I couldn't find a 
simpler way to put it.

2. In storing structs larger than a threshold. I know how to do that and 
there's a bugzilla on it, just haven't gotten around to implementing it.

Other than that it compares very favorably with other implementations 
I've written and read. In particular it has the same "bigger fish" 
design that std.algorithm has: it includes alternative designs as 
particular cases.

> Also, given that only a very few operations can ever be supported by 
> Variant, I think it's not a big deal if Variant never lets you do 
> anything interesting with the stored values besides boxing, unboxing, 
> equality testing, hashing, and any standard reflection stuff that is 
> available.

Not quite getting that. (Extensibility wasn't an essential concern for 
Phobos' Variant.) So yes, there are some primitives that variants should 
support. The point is making those primitives fast, otherwise 
dynamic-typed programming in D wouldn't be compelling.

That being said, I never ran speed comparisons, so I expect I'll be 
thoroughly surprised.


Andrei