partial class

[Sergey Gromov]

Fri, 31 Oct 2008 21:39:42 +0300, Denis Koroskin wrote:

> On Fri, 31 Oct 2008 20:59:23 +0300, KennyTM~ <kennytm at gmail.com> wrote:
> 
>> Denis Koroskin wrote:
>>> On Fri, 31 Oct 2008 20:06:42 +0300, KennyTM~ <kennytm at gmail.com> wrote:
>>>
>>>> Denis Koroskin wrote:
>>>>> On Fri, 31 Oct 2008 17:37:42 +0300, Mike James <foo at 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.

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.