Ary Borenszweig Wrote:

> Mike James wrote:
> > Not sure if this has been suggested before as an addition to D but what about introducing a partial class as per C# - with all the benefits it would bring...
> 
> 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 lot in C# lately, and I never needed a partial class)
> 
> 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.

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 what about introducing a partial class as per C# - with all the 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.)

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 what about introducing a partial class as per C# - with all the 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.

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.

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.

In fact in C# all partial classes must be compiled to the same assembly (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

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?

Mike James escribió:
> Not sure if this has been suggested before as an addition to D but what about introducing a partial class as per C# - with all the 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() { }

}

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

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.

Ary Borenszweig wrote:
> Mike James escribió:
>> Not sure if this has been suggested before as an addition to D but what about introducing a partial class as per C# - with all the 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.