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