Thread overview
Feature request: Partial Class Definitions (C#)
Jan 17, 2005
Lionello Lunesu
Module specs - Re: Feature request: Partial Class Definitions (C#)
Jan 17, 2005
Mark T
Jan 17, 2005
Norbert Nemec
Jan 18, 2005
Dave
Jan 18, 2005
Norbert Nemec
January 17, 2005
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 specialized "striper" tool. Today I found in the C# specification an implementation of the functionality that I was looking for. ¿Would it be too late/difficult to add it to the language?


From the C# 2.0 specification:

> Partial Class Definitions (C#)
>
> 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
January 17, 2005
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.


January 17, 2005
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 specialized "striper" tool. Today I found in the C# specification an implementation of the functionality that I was looking for. ¿Would it be too late/difficult to add it to the language?
January 17, 2005
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.
>
>


January 17, 2005
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 specialized "striper" tool. Today I found in the C# specification an 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();
  ...
 }
}
------------------

January 18, 2005
"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 specialized "striper" tool. Today I found in the C# specification an 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 could be defined over several source files w/o the C# 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..


January 18, 2005
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 aggragates could be defined over several source files w/o the C# 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..