class extensions

[Bill Baxter]

Brad Roberts wrote:
> 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.

Yeh, that should help some.  But that doesn't seem to do anything about 
foo.bar() inside a class being treated as this.bar(foo).  I think that 
just shouldn't happen ever.  Maybe that's just a bug, though.  In fact I 
think I'll go file it as one right now.

--bb