class extensions

[Brad Roberts]

On Fri, 31 Aug 2007, Bill Baxter wrote:

> 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

Don't overlook the changes upcoming in 2.0 to the overload resolution 
logic.  They'll greatly reduce (if not eliminate) the problem.  Many of 
the changes in 2.0 in isolation might introduce problems, but together 
make for a more powerful whole.

Later,
Brad