class extensions

Bill Baxter dnewsgroup at billbaxter.com
Thu Aug 30 12:25:12 PDT 2007


kris wrote:
> Lutger wrote:
>> kris wrote:

> And it potentially introduces additional namespace issues, hijacking 
> issues, and compilation errors for large and/or long-term software 
> development projects. The commercial-development space is where D ought 
> to target, if it's to rise well above being just another enthusiasts 
> playground :p

Namespace issues are why I don't currently find much use for the array 
trick.  If you put your array trick functions in a module, they're 
mostly going to have short names like "find" and "index".  So if you 
import that module normally it will clobber a valuable chunk of your 
namespace with little words like that.  But doing a static or renamed 
import causes the things not to work.  "arrayfn.find" can't be used as a 
property.  Ok so you can static import and then alias just the ones you 
want to use in the current module, possibly down at function scope to 
limit the namespace clashing.  But that's kind of a pain.

The error messages are also not very intuitive currently.  You type 
foo.bar(x,y) and get the error message "bar does not match types (int, 
int, int)"    Wait -- I'm not even calling bar with three args!?  Oh yeh 
that member syntax thing.  And if there really *is* a member with that 
name in the current context then it will shadow the external one even 
though it *looks* like foo.bar should be unambiguously scoped by foo.

These are from recent experience trying to emulate C++ iterators on top 
of D arrays.  For instance I wanted to be able to say  darray.begin() to 
get an iterator to an array.  Forget it.  Most classes in which I want 
to use that trick already have their own 'begin()' member which shadows 
the external begin(T)(T[]) function.

So my feeling is that for this to be more useful:
1) Extension members should be marked as such and *only* be allowed to 
be called with member syntax.  Those not marked as such will not be 
allowed to be called with member syntax.  (if you need both then it's 
easy enough to write a trivial forwarding function.)

2) Inside a class/struct scope, lookup of foo.bar should ignore methods 
of the local class.  (this would be a natural side effect of #1 though. 
  it already means extension members would do lookup differently than 
normal function lookup)

--bb



More information about the Digitalmars-d mailing list