class extensions

Michael Deardeuff some at where.com
Wed Aug 29 11:56:00 PDT 2007


Robert Fraser Wrote:

> Michael Deardeuff Wrote:
> 
> > I am very excited about the future of D. Walter's and Andrei's talk at the conference was awesome.
> > 
> > However, there are still a few quirks to get out:
> > This is regarding slide 9 of the presentation.
> > 
> > I noticed that most people at the conference liked the idea of extending library classes, but were not to pleased with the interchangability of 
> > ---
> > foo(a, args)
> > ---
> > and
> > ---
> > a.foo(args)
> > ---
> > like the arrays have.
> 
> Really? I got the feeling it was very well-received. I like the idea quite a bit, not necessarily just for class extensions (I think it might encourage a lower degree of encapsulation, although if the fields are package-private this might be mitigated by adding class extensions in other modules in the same package), but for primitive types.
> 
> > 
> > I have a suggestion: class extensions kindof like C#'s partial classes
> > ----
> > class A {...}
> > ...
> > extension class A {
> >    void foo(args) {...}
> > }
> > ...
> > a.foo(args);
> > ----
> > (maybe the syntax could be "class extension A" or "extension A"...)
> > 
> > In this way class extensions are clearly marked and the syntax is consistent.
> > 
> > It would be easy to add interfaces to the library class:
> > 
> > extension A : Visitable {
> >    void accept(Visitor v) {...}
> > }
> > 
> > Just an idea for you guys, Walter, Andrei, and the community.
> > 
> > --Michael Deardeuff
> > 
> 
> I proposed this a while ago, and I agree this would be a good idea. However, the more I think about it, the more I realize that in a native-compiled language we're talking vtable problems - how do we know when the vtable is finished? If partials are cross-module, it would require recompilation of every involved module, and just be generally problematic.

Excellent point. Blast.
I think it still _is_ a good idea if you scrap the inheritance/vtable problem and only allow extension classes to use the syntax "a.foo(...);"
I guess what I'm getting at is, I don't like the prospect of working with code that in one line is "foo(a, ...);" and the next "a.foo(...);" With the extension class bit it makes it clear that only methods meant as a class extension can (and must) use the "a.foo();" syntax, which I prefer.
And, of course,  I'm in here for myself. j/k. But not really.

--Michael Deardeuff



More information about the Digitalmars-d mailing list