class extensions

[kris]

Bill Baxter wrote:
> 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


Amen