www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - partial class

reply Mike James <foo bar.com> writes:
Not sure if this has been suggested before as an addition to D but what about


-=mike=-
Oct 31 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Mike James wrote:
 Not sure if this has been suggested before as an addition to D but what about

To my understanding, partial classes were introduced by Microsoft to make it easier for *them* to rewrite the UI code coming from a designer without having to watch out for user code. That is, whenever you change controls in the designer, now they just need to rewrite the .designer.cs class and not worry about erasing or skipping code you defined besides UI code. Conclusion: the motivation is coming from the UI, and to make life easier for them. (Maybe there are other reasons? I've been programming a Since D doesn't have a UI designer or nothing is integrated that much... what would you use partial classes for? If it's not for that reason, I think it makes it harder to know where is defined the code you are looking for.
Oct 31 2008
next sibling parent reply =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Ary,

 Conclusion: the motivation is coming from the UI, and to make life
 easier for them. (Maybe there are other reasons? I've been programming

 
 Since D doesn't have a UI designer or nothing is integrated that
 much... what would you use partial classes for?
 
 If it's not for that reason, I think it makes it harder to know where
 is defined the code you are looking for.
One place I've used them is when calling web-services. Most web-services calls need to generate a very specific XML document and building this manually means that methods grow hundreds of lines. I use partial class to separate each of this monster methods form connection pooling and other concerns of the same class: ServiceConnection.cs // Connection pooling ServiceConnection.OTA_AirAvailRQ.cs ServiceConnection.OTA_AirBookRQ.cs ... An the usage is like this: using (var conn = new ServiceConnection(connectionString)) { conn.Open(); var result = conn.OTA_AirAvailRQ(...); ... } You might say that we could separate things into several objects but that's the whole point of the Facade pattern: Making one big call with all the data needed to avoid several round trips over a slow network. Other place where I've used them is generating code from say a diagram or a database and still having a way to write custom methods for some classes. I (generally) don't need to look at the code generated by a tool but might want to add custom code in another file (so that it doesn't get overwritten if the tool is run again). For example, I can generate a state machine from a diagram and still be able to implement some methods in user-code: // MyStateMachine.generated.cs partial class StateA { partial void OnEnter(); partial void OnLeave(); // Other code that calls OnEnter() and OnLeave(); } // MyStateMachine.cs (Editable by the user) partial class StateA { partial void OnEnter() { // do something when entering A. } } This two uses have nothing to do with GUI and a lot to do with separating concerns of code in different files. I really wish D 2.0 could get this feature before release.
Oct 31 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Julio Csar Carrascal Urquijo wrote:
 Hello Ary,
 
 Conclusion: the motivation is coming from the UI, and to make life
 easier for them. (Maybe there are other reasons? I've been programming


 Since D doesn't have a UI designer or nothing is integrated that
 much... what would you use partial classes for?

 If it's not for that reason, I think it makes it harder to know where
 is defined the code you are looking for.
One place I've used them is when calling web-services. Most web-services calls need to generate a very specific XML document and building this manually means that methods grow hundreds of lines. I use partial class to separate each of this monster methods form connection pooling and other concerns of the same class: ServiceConnection.cs // Connection pooling ServiceConnection.OTA_AirAvailRQ.cs ServiceConnection.OTA_AirBookRQ.cs ... An the usage is like this: using (var conn = new ServiceConnection(connectionString)) { conn.Open(); var result = conn.OTA_AirAvailRQ(...); ... } You might say that we could separate things into several objects but that's the whole point of the Facade pattern: Making one big call with all the data needed to avoid several round trips over a slow network.
Model / view / presenter? http://martinfowler.com/eaaDev/SupervisingPresenter.html I'm not sure what you mean by "avoid several round trips over a slow network" -- having one extra class won't force that. It's the difference between your view generating a partial request and your view generating a complete request (and perhaps submitting it at the same time). You'd have the exact same approach with partial classes as with multiple classes.
Nov 01 2008
parent reply =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Christopher,

 Model / view / presenter?
 http://martinfowler.com/eaaDev/SupervisingPresenter.html
 I'm not sure what you mean by "avoid several round trips over a slow
 network" -- having one extra class won't force that. It's the
 difference between your view generating a partial request and your
 view generating a complete request (and perhaps submitting it at the
 same time). You'd have the exact same approach with partial classes as
 with multiple classes.
This section of the system is a rewrite of and older system where multiple classes where used to send partial messages. I used this pattern to aggregate messages in one SOAP envelop. You are right that multiple classes doesn't imply multiple messages but putting all calls on one class surely helps making sure those messages are aggregated. The downside is of course the class grows pretty rapidly but thats where partial classes come into play :D My point with the example is that Facade pattern benefits from "partial" because the point of the pattern is to provide a coarse grained interface to the client.
Nov 01 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Julio Csar Carrascal Urquijo wrote:
 Hello Christopher,
 
 Model / view / presenter?
 http://martinfowler.com/eaaDev/SupervisingPresenter.html
 I'm not sure what you mean by "avoid several round trips over a slow
 network" -- having one extra class won't force that. It's the
 difference between your view generating a partial request and your
 view generating a complete request (and perhaps submitting it at the
 same time). You'd have the exact same approach with partial classes as
 with multiple classes.
This section of the system is a rewrite of and older system where multiple classes where used to send partial messages. I used this pattern to aggregate messages in one SOAP envelop. You are right that multiple classes doesn't imply multiple messages but putting all calls on one class surely helps making sure those messages are aggregated. The downside is of course the class grows pretty rapidly but thats where partial classes come into play :D
Storing all the data in one class makes sure those messages are aggregated. The methods to manipulate that data can be in a second class if that's reasonable, and the methods to determine how to manipulate that class can be in a third.
 My point with the example is that Facade pattern benefits from "partial" 
 because the point of the pattern is to provide a coarse grained 
 interface to the client.
In this case, you can determine what the interface is -- the presenter or the view. If you want to provide both a low level interface and a high level interface, inheritance is a reasonable facsimile of partial classes. Otherwise, I'd prefer MVP.
Nov 02 2008
prev sibling parent Mike James <foo bar.com> writes:
Ary Borenszweig Wrote:

 Mike James wrote:
 Not sure if this has been suggested before as an addition to D but what about

To my understanding, partial classes were introduced by Microsoft to make it easier for *them* to rewrite the UI code coming from a designer without having to watch out for user code. That is, whenever you change controls in the designer, now they just need to rewrite the .designer.cs class and not worry about erasing or skipping code you defined besides UI code. Conclusion: the motivation is coming from the UI, and to make life easier for them. (Maybe there are other reasons? I've been programming a Since D doesn't have a UI designer or nothing is integrated that much... what would you use partial classes for? If it's not for that reason, I think it makes it harder to know where is defined the code you are looking for.
Yes - I was considering the UI case. Sometime soon D will grow from a "systems programming" language and maybe it would be useful to split that functionality. I have also seen the arguement put forward for when very large classes are created multiple software engineers can work on it - though whether this is a good argument for it I'm not sure. Regards, Mike.
Oct 31 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Mike James wrote:
 Not sure if this has been suggested before as an addition to D but what about

 
 -=mike=-
I like uniform function calling syntax (a.method(x) <=> method(a, x)) more, which addresses some syntactical benefits of partial class. But you can't have virtual inheritance, extra members, and only a few operators can be overloaded*. IIRC this suggestion has been raised quite a number of times but are rejected. I believe it is the difficulty to link classes across only compiled to a higher level byte code. (*: Only opStar (opDeref) can be overloaded for an array as far as I've tested.)
Oct 31 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Oct 31, 2008 at 10:53 AM, KennyTM~ <kennytm gmail.com> wrote:

 a higher level byte code.
nothing to do with its reflection capabilities. Information about types and symbols is completely separate from code, and even a Additionally, CIL is - according to its namesake, "Common Intermediate Language" - not really meant to be executed directly, and is most of the time just-in-time compiled to native machine code before execution.
 (*: Only opStar (opDeref) can be overloaded for an array as far as I've
 tested.)
That seems.. odd. Maybe it's a bug? I wasn't aware that you should be able to overload operators on basic types.
Oct 31 2008
parent KennyTM~ <kennytm gmail.com> writes:
Jarrett Billingsley wrote:
 On Fri, Oct 31, 2008 at 10:53 AM, KennyTM~ <kennytm gmail.com> wrote:

 a higher level byte code.
nothing to do with its reflection capabilities. Information about types and symbols is completely separate from code, and even a Additionally, CIL is - according to its namesake, "Common Intermediate Language" - not really meant to be executed directly, and is most of the time just-in-time compiled to native machine code before execution.
 (*: Only opStar (opDeref) can be overloaded for an array as far as I've
 tested.)
That seems.. odd. Maybe it's a bug? I wasn't aware that you should be able to overload operators on basic types.
This may be a bug for array types, but should not for custom types. Because the a.method(b) syntax is based on the one now existed on arrays, it's natural for me to test if operator overloading really works on arrays first. (Although I don't see any value dereferencing an array.)
Oct 31 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:

 Not sure if this has been suggested before as an addition to D but what  

 would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Oct 31 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Denis Koroskin wrote:
 On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:
 
 Not sure if this has been suggested before as an addition to D but 

 benefits it would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Something like this: partial class A { int someMember; public A(int x) { someMember = x; } } // Far, far apart partial class A { public int getSomeMember() { return someMember; } } class X { static void Main() { var someA = new A(12); System.Console.WriteLine(someA.getSomeMember()); } }
Oct 31 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 31 Oct 2008 20:06:42 +0300, KennyTM~ <kennytm gmail.com> wrote:

 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:

 Not sure if this has been suggested before as an addition to D but  

 benefits it would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Something like this: partial class A { int someMember; public A(int x) { someMember = x; } } // Far, far apart partial class A { public int getSomeMember() { return someMember; } } class X { static void Main() { var someA = new A(12); System.Console.WriteLine(someA.getSomeMember()); } }
Is this worth the trouble? You can have class A { int someMember; public A(int x) { someMember = x; } public int getSomeMember(); } in one module and implement getSomeMember() in another module. I believe all the class methods should be defined in one place so that user don't need to import class definition from multiple places. This also makes semantic analysis more complex.
Oct 31 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Denis Koroskin wrote:
 On Fri, 31 Oct 2008 20:06:42 +0300, KennyTM~ <kennytm gmail.com> wrote:
 
 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:

 Not sure if this has been suggested before as an addition to D but 

 benefits it would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Something like this: partial class A { int someMember; public A(int x) { someMember = x; } } // Far, far apart partial class A { public int getSomeMember() { return someMember; } } class X { static void Main() { var someA = new A(12); System.Console.WriteLine(someA.getSomeMember()); } }
Is this worth the trouble? You can have class A { int someMember; public A(int x) { someMember = x; } public int getSomeMember(); } in one module and implement getSomeMember() in another module. I believe all the class methods should be defined in one place so that user don't need to import class definition from multiple places. This also makes semantic analysis more complex.
Right. It may be useful when you want to provide additional function, e.g. a getRandom method to a NormalDistribution class where normally that function would not be needed. module math.normaldistrib; partial class NormalDistribution : IDistribution { double mean() { ... } double stdev() { ... } // etc. } in another module: module random.normal; partial class NormalDistribution : IRandomGenerator { double getRandom() { // complete something the math. package's author // don't bother to do. ... } } But again I said this can be solved with equating a.method(b) to method(a,b), which has been in the TODO list long long time ago. double getRandom(NormalDistribution nd) { // a catch: you can't access private members here. ... } .NET uses partial class to separate generated UI code and custom UI code, though subclassing the UI look and do the implementation in that subclass also solves the problem. (Qt works in this way.)
Oct 31 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 31 Oct 2008 20:59:23 +0300, KennyTM~ <kennytm gmail.com> wrote:

 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 20:06:42 +0300, KennyTM~ <kennytm gmail.com> wrote:

 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:

 Not sure if this has been suggested before as an addition to D but  

 benefits it would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Something like this: partial class A { int someMember; public A(int x) { someMember = x; } } // Far, far apart partial class A { public int getSomeMember() { return someMember; } } class X { static void Main() { var someA = new A(12); System.Console.WriteLine(someA.getSomeMember()); } }
Is this worth the trouble? You can have class A { int someMember; public A(int x) { someMember = x; } public int getSomeMember(); } in one module and implement getSomeMember() in another module. I believe all the class methods should be defined in one place so that user don't need to import class definition from multiple places. This also makes semantic analysis more complex.
Right. It may be useful when you want to provide additional function, e.g. a getRandom method to a NormalDistribution class where normally that function would not be needed. module math.normaldistrib; partial class NormalDistribution : IDistribution { double mean() { ... } double stdev() { ... } // etc. } in another module: module random.normal; partial class NormalDistribution : IRandomGenerator { double getRandom() { // complete something the math. package's author // don't bother to do. ... } } But again I said this can be solved with equating a.method(b) to method(a,b), which has been in the TODO list long long time ago. double getRandom(NormalDistribution nd) { // a catch: you can't access private members here. ... } .NET uses partial class to separate generated UI code and custom UI code, though subclassing the UI look and do the implementation in that subclass also solves the problem. (Qt works in this way.)
Note that partial classes also compromise code security: partial class Foo { private int secret; } // HA-HA-HACK! partial class Foo { int hack() { return secret; } } I wouldn't trust these.
Oct 31 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 31 Oct 2008 21:39:42 +0300, Denis Koroskin wrote:

 On Fri, 31 Oct 2008 20:59:23 +0300, KennyTM~ <kennytm gmail.com> wrote:
 
 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 20:06:42 +0300, KennyTM~ <kennytm gmail.com> wrote:

 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:

 Not sure if this has been suggested before as an addition to D but  

 benefits it would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Something like this: partial class A { int someMember; public A(int x) { someMember = x; } } // Far, far apart partial class A { public int getSomeMember() { return someMember; } } class X { static void Main() { var someA = new A(12); System.Console.WriteLine(someA.getSomeMember()); } }
Is this worth the trouble? You can have class A { int someMember; public A(int x) { someMember = x; } public int getSomeMember(); } in one module and implement getSomeMember() in another module. I believe all the class methods should be defined in one place so that user don't need to import class definition from multiple places. This also makes semantic analysis more complex.
Right. It may be useful when you want to provide additional function, e.g. a getRandom method to a NormalDistribution class where normally that function would not be needed. module math.normaldistrib; partial class NormalDistribution : IDistribution { double mean() { ... } double stdev() { ... } // etc. } in another module: module random.normal; partial class NormalDistribution : IRandomGenerator { double getRandom() { // complete something the math. package's author // don't bother to do. ... } } But again I said this can be solved with equating a.method(b) to method(a,b), which has been in the TODO list long long time ago. double getRandom(NormalDistribution nd) { // a catch: you can't access private members here. ... } .NET uses partial class to separate generated UI code and custom UI code, though subclassing the UI look and do the implementation in that subclass also solves the problem. (Qt works in this way.)
Note that partial classes also compromise code security: partial class Foo { private int secret; } // HA-HA-HACK! partial class Foo { int hack() { return secret; } } I wouldn't trust these.
C++ and D are not Java. You cannot base any security upon member access attributes because any member is accessible via a minimal amount of pointer magic. But, with partial classes, you can definitely kiss goodbye to encapsulation.
Nov 07 2008
prev sibling parent reply ore-sama <spam here.lot> writes:
KennyTM~ Wrote:

 Right. It may be useful when you want to provide additional function, 
 e.g. a getRandom method to a NormalDistribution class where normally 
 that function would not be needed.
 
    module math.normaldistrib;
 
    partial class NormalDistribution : IDistribution {
      double mean() { ... }
      double stdev() { ... }
      // etc.
    }
 
 in another module:
 
    module random.normal;
 
    partial class NormalDistribution : IRandomGenerator {
      double getRandom() {
        // complete something the math. package's author
        // don't bother to do.
        ...
      }
    }
I thought, partial classes work in a different way. So that after compilation partial class is no more partial and considering dmd's way 1 source -> 1 obj it's hard to separate class into 2 source files.
Oct 31 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
ore-sama wrote:
 KennyTM~ Wrote:
 
 Right. It may be useful when you want to provide additional function, 
 e.g. a getRandom method to a NormalDistribution class where normally 
 that function would not be needed.

    module math.normaldistrib;

    partial class NormalDistribution : IDistribution {
      double mean() { ... }
      double stdev() { ... }
      // etc.
    }

 in another module:

    module random.normal;

    partial class NormalDistribution : IRandomGenerator {
      double getRandom() {
        // complete something the math. package's author
        // don't bother to do.
        ...
      }
    }
I thought, partial classes work in a different way. So that after compilation partial class is no more partial and considering dmd's way 1 source -> 1 obj it's hard to separate class into 2 source files.
(ref: http://msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx): "All partial-type definitions meant to be parts of the same type must be defined in the same assembly and the same module (.exe or .dll file). Partial definitions cannot span multiple modules." So yes, after compiling they are no longer partial. You may say you have the freedom to choose which part you really want to include in your program, which has no much benefit than subclassing it. In DMD it can work when you cat several sources together. :P
Oct 31 2008
parent reply ore-sama <spam here.lot> writes:
KennyTM~ Wrote:

 So yes, after compiling they are no longer partial. You may say you have 
 the freedom to choose which part you really want to include in your 
 program, which has no much benefit than subclassing it.
did you mean conditional compilation?
Oct 31 2008
parent KennyTM~ <kennytm gmail.com> writes:
ore-sama wrote:
 KennyTM~ Wrote:
 
 So yes, after compiling they are no longer partial. You may say you have 
 the freedom to choose which part you really want to include in your 
 program, which has no much benefit than subclassing it.
did you mean conditional compilation?
without stuffing everything in one file.
Nov 01 2008
prev sibling parent reply Brian <digitalmars brianguertin.com> writes:
On Sat, 01 Nov 2008 01:06:42 +0800, KennyTM~ wrote:

 Denis Koroskin wrote:
 On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo bar.com> wrote:
 
 Not sure if this has been suggested before as an addition to D but

 benefits it would bring...

 -=mike=-
I must be missing something, but D already supports defining class methods in one file and implementing them in another one.
Something like this: partial class A { int someMember; public A(int x) { someMember = x; } } // Far, far apart partial class A { public int getSomeMember() { return someMember; } } class X { static void Main() { var someA = new A(12); System.Console.WriteLine(someA.getSomeMember()); } }
class A { int someMember; public void init(int x) { someMember = x; } } // Far, far apart class B : A { public int getSomeMember() { return someMember; } } void main() { auto someA = new B; someA.init(12); writefln(someA.getSomeMember()); } // Partial class don't seem useful to me. It seems to me they would create more problems then they could solve.
Oct 31 2008
parent BCS <ao pathlink.com> writes:
Reply to Brian,

 class A {
 int someMember;
 public void init(int x) { someMember = x; }
 }
 // Far, far apart
 
 class B : A {
 public int getSomeMember() { return someMember; }
 }
 void main() {
 auto someA = new B;
 someA.init(12);
 writefln(someA.getSomeMember());
 }
 // Partial class don't seem useful to me. It seems to me they would
 create more problems then they could solve.
 
not that I want partial classes // In a lib you are using A Foo(){ return new A(); } // your code auto foo = Foo(); /// now call getSomeMember on foo
Oct 31 2008
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Mike James escribi:
 Not sure if this has been suggested before as an addition to D but what about

Julio's second example convinced me that partial classes are useful. But in D you can already do that, sort of: class Foo { // Methods handled by the user void one() { } void two() { } // ... mixin GeneratedFoo!(); } // far, far away template GeneratedFoo() { void three() { } void four() { } }
Oct 31 2008
next sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Ary Borenszweig wrote:
 Mike James escribió:
 Not sure if this has been suggested before as an addition to D but 

 benefits it would bring...
Julio's second example convinced me that partial classes are useful. But in D you can already do that, sort of: class Foo { // Methods handled by the user void one() { } void two() { } // ... mixin GeneratedFoo!(); } // far, far away template GeneratedFoo() { void three() { } void four() { } }
You can’t just “monkey-patch” the original class, though. With partial classes you could just inject some additional code to the original class. I don’t think partial classes fit into D. You can do the same thing via abstract classes and subclassing without altering the original class/interface.
Nov 01 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Alexander Pánek escribió:
 Ary Borenszweig wrote:
 Mike James escribió:
 Not sure if this has been suggested before as an addition to D but 

 benefits it would bring...
Julio's second example convinced me that partial classes are useful. But in D you can already do that, sort of: class Foo { // Methods handled by the user void one() { } void two() { } // ... mixin GeneratedFoo!(); } // far, far away template GeneratedFoo() { void three() { } void four() { } }
You can’t just “monkey-patch” the original class, though. With partial classes you could just inject some additional code to the original class.
same assembly, and it also must be defined as "partial class". So if you can "monkey-patch" a partial class, you could just as easily go to the class' source code and inject that additional code. Partial classes are just a convenience for defining many pieces of a class in multiple files.
 
 I don’t think partial classes fit into D. You can do the same thing via 
 abstract classes and subclassing without altering the original 
 class/interface.
Yes, I don't like much the idea either. I like to have all of a class' code in one file. Otherwise, at least for me, it makes it hard to follow code, to know where something is defined.
Nov 01 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Ary Borenszweig wrote:
 Alexander Pánek escribió:
 You can’t just “monkey-patch” the original class, though. With partial 
 classes you could just inject some additional code to the original class.
same assembly, and it also must be defined as "partial class". So if you can "monkey-patch" a partial class, you could just as easily go to the class' source code and inject that additional code.
can also use "extension methods" for adding new methods to an already-defined class, no matter what assembly it comes from. Even the core classes, like String, can be modified using extension methods. The D trick where "static method(a, b)" is the same as "a.method(b)" is is that the trick can only be used on functions defined as extension methods, not for any arbitrary function. I like that. --benji
Nov 01 2008
prev sibling parent reply =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Ary,

 Mike James escribi:
 Julio's second example convinced me that partial classes are useful.
 But in D you can already do that, sort of:
Yes that's possible right now but, sadly, it can't do this: class Foo { mixin GeneratedFoo!(); } // far, far away template GeneratedFoo() { void three() { } void four() { one(); // Might not be implemented by the class } } Which means that Foo has to be polluted with default implementations of every // Controlled by the user. partial class Foo { } // Controlled by the tool. partial class Foo { partial void one(); void four() { one(); } }
Nov 01 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Julio Csar Carrascal Urquijo escribi:
 Hello Ary,
 
 Mike James escribi:
 Julio's second example convinced me that partial classes are useful.
 But in D you can already do that, sort of:
Yes that's possible right now but, sadly, it can't do this: class Foo { mixin GeneratedFoo!(); } // far, far away template GeneratedFoo() { void three() { } void four() { one(); // Might not be implemented by the class } } Which means that Foo has to be polluted with default implementations of // Controlled by the user. partial class Foo { } // Controlled by the tool. partial class Foo { partial void one(); void four() { one(); } }
Wow, I didn't know there were also partial methods. Something new. :-)
Nov 01 2008
parent =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Ary,

 Julio Csar Carrascal Urquijo escribi:
 Wow, I didn't know there were also partial methods. Something new. :-)
 
Nov 01 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Julio Csar Carrascal Urquijo wrote:
 Which means that Foo has to be polluted with default implementations of 

 
 // Controlled by the user.
 partial class Foo
 {
 }
 
 // Controlled by the tool.
 partial class Foo
 {
     partial void one();
 
     void four()
     {
         one();
     }
 }
 
 
What happens if one is not implemented? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
parent =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Bruno,

 What happens if one is not implemented?
 
Since all partial classes are known at compile time the compiler generates an empty method. That means that the return type should always be void but out parameters can be used.
Nov 07 2008