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=-

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.

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...
> 
> -=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 libraries. Note that C# have richer RTTI ability than D because C# is only compiled to a higher level byte code.

(*: Only opStar (opDeref) can be overloaded for an array as far as I've tested.)

On Fri, Oct 31, 2008 at 10:53 AM, KennyTM~ <kennytm@gmail.com> wrote:
> Note that C# have richer RTTI ability than D because C# is only compiled to a higher level byte code.

The fact that C# is compiled, on first pass, to CIL has literally nothing to do with its reflection capabilities.  Information about types and symbols is completely separate from code, and even a language like D could have RTTI as expressive and flexible as C#. 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.

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
> 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.

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.

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.

Jarrett Billingsley wrote:
> On Fri, Oct 31, 2008 at 10:53 AM, KennyTM~ <kennytm@gmail.com> wrote:
>> Note that C# have richer RTTI ability than D because C# is only compiled to
>> a higher level byte code.
> 
> The fact that C# is compiled, on first pass, to CIL has literally
> nothing to do with its reflection capabilities.  Information about
> types and symbols is completely separate from code, and even a
> language like D could have RTTI as expressive and flexible as C#.
> 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.)

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());
    }
}

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.

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 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());
>      }
> }

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.