Pulling some builtin logic out

[Koroskin Denis]

On Mon, 31 Mar 2008 21:03:07 +0400, Kaja <kaja.fumei at gmail.com> wrote:

> Walter wrote in the docs:
>> Associative Arrays
>>
>> The main benefit for this is, once again, syntactic sugar. An
>> associative array keying off of a type T and storing an int value is
>> naturally written as:
>>
>> int[T] foo;
>> rather than:
>>
>> import std.associativeArray;
>> ...
>> std.associativeArray.AA!(T, int) foo;
>> Builtin associative arrays also offer the possibility of having  
>> associative
>> array literals, which are an often requested additional feature.
>
> And he's not big on standrdizing a library, but what if we could have  
> the syntactic sugar and flexibility?  What if int[T] mapped to an  
> interface for associative arrays rather than a class or builtin type?   
> Standardize the interface and not the implementation.
>
> Then someone could still do something like this:
>
> class MyAA(K, V) : std.associativeArray(K, V)
> {
>   // insert my implementation
> }
>
> // compiler choice.  probably builtin implementation
> int[string] foo;
>
> // programmer choice.
> int[string] foo2 = new MyAA!(string, int)();
>
> Thoughts?  Comments?
>


Yes, it's a good idea, but your solution introduces virtual function calls  
that could kill performance.
Much better approch would be the following:

- Provide an "interface" that built-in AAs implement.
- Allow user-defined types to implement this interface.
- Allow these derived types to benefit from all the syntax sugar, used by  
built-in containers.
- Allow users to replace built-in containers with user-defined ones.  
(arguable)

Third point is necessary since there are still some tricks that can't be  
used by programmer like 'in' operator in AAs.
This way containers could be replaced by user-defined types partially or  
completely.