www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pulling some builtin logic out

reply Kaja <kaja.fumei gmail.com> writes:
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?
Mar 31 2008
next sibling parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Mon, 31 Mar 2008 21:03:07 +0400, Kaja <kaja.fumei 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 =3D new MyAA!(string, int)();

 Thoughts?  Comments?

Yes, it's a good idea, but your solution introduces virtual function cal= ls = 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 b= y = 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.
Mar 31 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 31 Mar 2008 19:36:59 +0200, Koroskin Denis <2korden+dmd gmail.com>  
wrote:

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

The in operator is overloadable via opIn and opIn_r, so that wouldn't really be a problem, I think. As for the other stuff, it sounds like a pleasant idea. -Simen
Mar 31 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Kaja 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?

I'd assume the user would be given some control, so she could, say, use Judy ( http://judy.sourceforge.net ) or her own implementation rather than a built-in/standard library implementation and look down on everyone else's cache inefficiencies?
Mar 31 2008
parent Kaja <kaja.fumei gmail.com> writes:
Robert Fraser Wrote:

 Kaja 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?

I'd assume the user would be given some control, so she could, say, use Judy ( http://judy.sourceforge.net ) or her own implementation rather than a built-in/standard library implementation and look down on everyone else's cache inefficiencies?

Yeah, the purpose of this suggestion is so that D would define an interface for associate arrays (and potentially other builtin types) so that the programmer can use any class implements that interface regardless of whether its in a standard, third party, or custom deisgned library.
Apr 01 2008