Daniel Keep wrote:
Andrei Alexandrescu wrote:
dsimcha wrote:
Well, now that I understand your proposal a little better, it makes
sense. I had
wondered why the current AA implementation uses RTTI instead of
templates. Even
better would be if only the default implementation were in Object, and
a user
could somehow override which implementation of AA is given the
blessing of pretty
syntax by some pragma or export alias or something, as long as the
implementation
conforms to some specified compile-time interface.
Great! For now, I'd be happy if at least the user could hack their
import path to include their own object.d before the stock object.d.
Then people can use straight D to implement the AssocArray they prefer.
Further improvements of the scheme will then become within reach!
Andrei
dmd -object=myobject.d stuff.d
That would require the user to duplicate everything in object, which is
a little messy. Maybe it would be a good idea to break object itself
into a bunch of public imports to core.internal.* modules, then allow this:
dmd -sub=core.internal.aa=myaa stuff.d
Of course, it's probably simpler still to have this:
dmd -aatype=myaa.AAType stuff.d
-- Daniel
Instead, what if the literal syntax was amended to take an optional type
name, like this:
// Defaults to using built-in associative array type
auto assocArray = [
"hello" : "world
];
// Uses my own custom type.
auto hashtable = MyHashTableType!(string, string) [
"hello" : "world
];
You could accomplish that pretty easily, as long as the custom type had
a no-arg constructor and a function with the signature:
void add(K key, V val)
--benji
