• Kaja (12/23) Mar 31 2008 And he's not big on standrdizing a library, but what if we could have th...
• Koroskin Denis (20/50) Mar 31 2008 =
• Simen Kjaeraas (6/19) Mar 31 2008 The in operator is overloadable via opIn and opIn_r, so that wouldn't
• Kaja (4/20) Mar 31 2008 But most of D's methods are virtual. Nobody minds that opEquals or toSt...
• bearophile (5/7) Mar 31 2008 You can use the opIn_r operator with no problems.
• Koroskin Denis (3/14) Mar 31 2008 My bad, didn't know it's already supported. :)
• Craig Black (3/5) Mar 31 2008 Yes! And you don't need virtual functions for polymorphism when you hav...
• Janice Caron (4/5) Mar 31 2008 It's completely usable. I've used it.
• Robert Fraser (5/37) Mar 31 2008 I'd assume the user would be given some control, so she could, say, use
• Kaja (2/40) Apr 01 2008 Yeah, the purpose of this suggestion is so that D would define an interf...

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?

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

"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

Kaja <kaja.fumei gmail.com> writes:

Koroskin Denis Wrote:
 
 Yes, it's a good idea, but your solution introduces virtual function calls  
 that could kill performance.

But most of D's methods are virtual.  Nobody minds that opEquals or toString
are virtual and they're used a lot.  Yes, it will be a performance hit for the
builtin implementation but would be the same for the programmer defined
implementations.  If they're going to have to use a custom class anyway, why
not allow them to have the syntax to go with it?  

Often in languages and compilers, you have to choose between flexibility and
speed, and that's a deicision for Walter.

 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.

Why couldn't a person use "in" on a user-defined AA?  According to the docs,
its overloadable with opIn (but no example on the page so maybe its not
supported anymore).

bearophile <bearophileHUGS lycos.com> writes:

Kaja:
 Often in languages and compilers, you have to choose between flexibility and
speed,

D AA are already plenty slow. So I'd try to find a way to have both speed and
flexibility.


 Why couldn't a person use "in" on a user-defined AA?  According to the docs,
its overloadable with opIn (but no example on the page so maybe its not
supported anymore).<

You can use the opIn_r operator with no problems.

Bye,
bearophile

"Koroskin Denis" <2korden+dmd gmail.com> writes:

On Mon, 31 Mar 2008 22:15:00 +0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Kaja:
 Often in languages and compilers, you have to choose between  
 flexibility and speed,

 D AA are already plenty slow. So I'd try to find a way to have both  
 speed and flexibility.


 Why couldn't a person use "in" on a user-defined AA?  According to the  
 docs, its overloadable with opIn (but no example on the page so maybe  
 its not supported anymore).<

 You can use the opIn_r operator with no problems.

 Bye,
 bearophile


My bad, didn't know it's already supported. :)

"Craig Black" <cblack ara.com> writes:

 D AA are already plenty slow. So I'd try to find a way to have both speed 
 and flexibility.

Yes!  And you don't need virtual functions for polymorphism when you have 
templates.

-Craig

"Janice Caron" <caron800 googlemail.com> writes:

On 31/03/2008, Kaja <kaja.fumei gmail.com> wrote:
 Why couldn't a person use "in" on a user-defined AA?  According to the docs,
its overloadable with opIn (but no example on the page so maybe its not
supported anymore).

It's completely usable. I've used it.

But of course, you'd use opIn_r(), not opIn(), because it's "element
in container", not "container in element".

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?

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.