www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feature request: Partial Class Definitions (C#)

reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Hi.

A long time ago I asked how to implement methods of a class in an 
external source file. The response I got from Walter was to use a 

implementation of the functionality that I was looking for. ¿Would it be 
too late/difficult to add it to the language?







 It is possible to split the definition of a class (or a struct, or an
 interface) over two or more source files. Each source file contains a
 section of the class definition, and all parts are combined when the
 application is compiled. There are several situations when splitting
 a class definition is desirable:

     * When working on large projects, spreading a class over separate
       files allows multiple programmers to work on it simultaneously.
     * When working with automatically generated source, code can be
       added to the class without having to re-create the source file.
       Visual Studio uses this approach when creating Windows Forms,
       Web Service wrapper code and so on. The programmer can create
       code that uses these classes, without having to edit the file
       created by Visual Studio.


I would add another:

* To easy the development of portable libraries that use completely
   different implementations to use features of the underlying operating
   system. Examples would be wxWidgets and Abiword, both projects
   maintain separate directories for each platform where specific
   implementation of certain features reside and the compilation is
   selected by their makefiles.


Thanks
Jan 17 2005
next sibling parent "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
Something similar: I've often wondered why I had to add private functions of 
a class to a public header file in C++. It would be nice (and safe) to be 
able to declare private functions in the source file/module. (Obviously, 
private variables are needed publically since they influence the size of an 
instance).

L.
Jan 17 2005
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I also pesonally very much like this functionality and the way it is 
implemented:

partial class Blah
{
    ...
}

And, to my understanding, all definitions of the class must use the 
keyword "partial"...

However, I can understand that this would probably complicate compilers 
a bit, but I'm not sure it would be that much.

-[Unknown]


 A long time ago I asked how to implement methods of a class in an 
 external source file. The response I got from Walter was to use a 

 implementation of the functionality that I was looking for. ¿Would it be 
 too late/difficult to add it to the language?
Jan 17 2005
prev sibling next sibling parent Mark T <Mark_member pathlink.com> writes:
It seems that in the long run D needs a formal way to publish a "specification"
of a module with all it's public entities. This would be useful for
libraries,etc where you don't have access to the source code. I suggest a
different extension like .ds or .dspec so the compiler would only parse it for
proper usage information. This is one place where the .h file has come in handy
over the years in C and C++. This is a different concept then Partial Class
Definitions but would fulfill this need: 


* To easy the development of portable libraries that use completely
   different implementations to use features of the underlying operating
   system. Examples would be wxWidgets and Abiword, both projects
   maintain separate directories for each platform where specific
   implementation of certain features reside and the compilation is
   selected by their makefiles.
Jan 17 2005
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Julio César Carrascal Urquijo wrote:

 A long time ago I asked how to implement methods of a class in an
 external source file. The response I got from Walter was to use a

 implementation of the functionality that I was looking for. ¿Would it be
 too late/difficult to add it to the language?


What about using a mixin to do the trick:

-----------------
module ModuleOfPartialClass;

template PartialClass() {
 void somefunction() {
  ...
 }
}
-----------------

-----------------
import ModuleOfPartialClass;

class MainClass {
 mixin PartialClass;

 void otherfunction() {
  ...
  somefunction();
  ...
 }
}
------------------
Jan 17 2005
parent reply "Dave" <Dave_member pathlink.com> writes:
"Norbert Nemec" <Norbert Nemec-online.de> wrote in message 
news:csgrjg$1uru$1 digitaldaemon.com...

 Julio César Carrascal Urquijo wrote:

 A long time ago I asked how to implement methods of a class in an
 external source file. The response I got from Walter was to use a

 implementation of the functionality that I was looking for. ¿Would it be
 too late/difficult to add it to the language?


 What about using a mixin to do the trick:

 -----------------
 module ModuleOfPartialClass;

 template PartialClass() {
 void somefunction() {
  ...
 }
 }
 -----------------

 -----------------
 import ModuleOfPartialClass;

 class MainClass {
 mixin PartialClass;

 void otherfunction() {
  ...
  somefunction();
  ...
 }
 }
 ------------------


What if mixins were taken a step further by the compiler so that aggragates 

"partial" for each definition of an aggragate? That way you could 
conditionally "augment" a class w/ import instead of inheritance. Something 
like:

main.d
---------------------
import std.stream, lib.foo;
version(baz) {
    import lib.baz;
} else {
    import lib.bar;
}
void main()
{
    Foo F = new Foo();
    F.aVar = 10;
    stdout.writefln("F.quux(10) = ",F.quux(10));
}
---------------------
foo.d
---------------------
module lib.foo;
class Foo {
package:
    int _aVar;
public:
    int aVar(int x) { return _aVar = x; }
    int aVar() { return _aVar; }
//  ...
/* The compiler would "auto-mixin" adjunct classes like lib.bar or lib.baz 
here */
}
---------------------
bar.d
---------------------
module lib.bar;
adjunct class Foo    // adjunct keyword ('auxiliary' functionality for class 
Foo)
{
    int quux(int x) { return _aVar * x; }
//  ...
}
---------------------
baz.d
---------------------
module lib.baz;
adjunct class Foo    // adjunct keyword ('auxiliary' functionality for class 
Foo)
{
    int quux(int x) { return _aVar + x; }
//  ...
}
---------------------

Just a thought..
Jan 17 2005
parent Norbert Nemec <Norbert Nemec-online.de> writes:
The only difference I see here is, that the main class does not need to
mention the included partial classes. I think, this is a drawback rather
than a feature. The compiler might be able to sort it out, but a human
reader will be confused like something.



Dave wrote:

 What if mixins were taken a step further by the compiler so that

 requirement of using "partial" for each definition of an aggragate? That
 way you could conditionally "augment" a class w/ import instead of
 inheritance. Something like:
 
 main.d
 ---------------------
 import std.stream, lib.foo;
 version(baz) {
     import lib.baz;
 } else {
     import lib.bar;
 }
 void main()
 {
     Foo F = new Foo();
     F.aVar = 10;
     stdout.writefln("F.quux(10) = ",F.quux(10));
 }
 ---------------------
 foo.d
 ---------------------
 module lib.foo;
 class Foo {
 package:
     int _aVar;
 public:
     int aVar(int x) { return _aVar = x; }
     int aVar() { return _aVar; }
 //  ...
 /* The compiler would "auto-mixin" adjunct classes like lib.bar or lib.baz
 here */
 }
 ---------------------
 bar.d
 ---------------------
 module lib.bar;
 adjunct class Foo    // adjunct keyword ('auxiliary' functionality for
 class Foo)
 {
     int quux(int x) { return _aVar * x; }
 //  ...
 }
 ---------------------
 baz.d
 ---------------------
 module lib.baz;
 adjunct class Foo    // adjunct keyword ('auxiliary' functionality for
 class Foo)
 {
     int quux(int x) { return _aVar + x; }
 //  ...
 }
 ---------------------
 
 Just a thought..
Jan 17 2005