www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Pulling some builtin logic out

reply 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).
Mar 31 2008
next sibling parent reply 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
Mar 31 2008
next sibling parent "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. :)
Mar 31 2008
prev sibling parent "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
Mar 31 2008
prev sibling parent "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".
Mar 31 2008