www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - class extensions

reply Michael Deardeuff <grignaak gmail.com> writes:
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.

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
Aug 29 2007
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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. The suggestion that cam eup in the other thread was to use templates: --- interface IFoo { int bar(); } template IFoo_Impl() { int bar() { return 3; } } interface IBaz { string quux(); } template IBaz_Impl() { string quux() { return "abc"; } } class Baz : IFoo, IBaz { mixin IFoo_Impl!(); mixin IBaz_Impl(); } ---
Aug 29 2007
prev sibling parent reply janderson <askme me.com> writes:
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.
 
 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'm on the camp that like the interchangeable method/function syntax because it will encourage people to write better code, rather then sticking everything into the class body. It also allows you to change methods into functions and visa versa without breaking the users code. -Joel
Aug 31 2007
parent janderson <askme me.com> writes:
janderson 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.

 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'm on the camp that like the interchangeable method/function syntax because it will encourage people to write better code, rather then sticking everything into the class body. It also allows you to change methods into functions and visa versa without breaking the users code. -Joel

Here's a thought. Will this work with C code such that we could for instance expose a class C++ in C like form and then use it in D like a regular class, and visa versa? Note of course would only applies to classes without V-Tables.
Aug 31 2007