Two questions about "partial classes"

[Gomaw Beoyr]

Two question about the "partial classes" (in the next wersion of
..NET).


Question 1
==========
Will partial classes (in the next version of C#) have to be
declared "partial" in ALL places.

I.e. do we have to need to write:

File 1:
public partial class AB {
public int A;
}

File 2:
public partial class AB {
public int B;
}

Or will it be possible to write:

File 1:
public class AB { // Omit "partial" here
public int A;
}

File 2:
public partial class AB {
public int B;
}

Note that in the latter case, it would be possible to extend
ANY class, e.g. the ValueType class:

Some file:
namespace System {
public partial class ValueType {
public double Inverse {
get {
return 1.0/(double)this;
}
}
}
}

which would add an "Inverse" property to the types float, double,
int and so on:

2.Inverse == 0.5
4.0.Inverse == 0.25

It would definitely be nice to have some kind of mechanism that
would make already implemented classes "partial", thus making it
possible to extend them this way.


Question 2
==========
Must the interfaces of partial classes be declared in all places?

I.e. do we have to write:

File 1:
public partial class X: IA, IB, IC, ID {
// Methods of interfaces IA and IB
}

File 2:
public partial class X: IA, IB, IC, ID {
// Methods of interfaces IC and ID
}

Or, will it be possible to write:

File 1:
public partial class X: IA, IB {
// Methods of interfaces IA and IB
}

File 2:
public partial class X: IC, ID {
// Methods of interfaces IC and ID
}

The second way would definitely make implementation easier.


/Gomaw

 

[Eric Gunnerson [MS]]

Answers below

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

Two question about the "partial classes" (in the next wersion of
.NET).


Question 1
==========
Will partial classes (in the next version of C#) have to be
declared "partial" in ALL places.

I.e. do we have to need to write:

File 1:
public partial class AB {
public int A;
}

File 2:
public partial class AB {
public int B;
}

Or will it be possible to write:

File 1:
public class AB { // Omit "partial" here
public int A;
}

File 2:
public partial class AB {
public int B;
}

Note that in the latter case, it would be possible to extend
ANY class, e.g. the ValueType class:

Some file:
namespace System {
public partial class ValueType {
public double Inverse {
get {
return 1.0/(double)this;
}
}
}
}

which would add an "Inverse" property to the types float, double,
int and so on:

2.Inverse == 0.5
4.0.Inverse == 0.25

It would definitely be nice to have some kind of mechanism that
would make already implemented classes "partial", thus making it
possible to extend them this way.

Partial classes are purely a compile-time construct, and all parts of the
class must be marked with partial. They aren't intended to be used to extend
system classes. I haven't thought about this deeply, but my guess is that
there could be some security issues in doing that, along with the problem of
possibly changing system-defined behavior.

Question 2
==========
Must the interfaces of partial classes be declared in all places?

I.e. do we have to write:

File 1:
public partial class X: IA, IB, IC, ID {
// Methods of interfaces IA and IB
}

File 2:
public partial class X: IA, IB, IC, ID {
// Methods of interfaces IC and ID
}

Or, will it be possible to write:

File 1:
public partial class X: IA, IB {
// Methods of interfaces IA and IB
}

File 2:
public partial class X: IC, ID {
// Methods of interfaces IC and ID
}

The second way would definitely make implementation easier.

Interfaces can be declared on any part of the partial class.

 

[Chad Myers]

Eric,

I know you've said this before, but I still don't
get the point of partial classes. From what I understand,
it's for situations like having Windows Forms designer
code in one file and all your implementation in another.

Is that really that big a of a deal with #region?

It seems you are adding a great deal of complexity
(and therefor potential for great abuse)
with very little return or benefit.

-c

 

[Daniel O'Connell]

I too am not sure if this is a good thing or not, but abuse comes very
commonly with everything(i really hope no one comes up with seriously
abusive ways to use generics, but you know as well as i do that as soon as
they come out publically there will be thousands of classes written with
them that doesn't need them), same as with all new features.
Anyway, in addition to chads comments, the problems this seems to solve
seems like something the IDE should handle more than the compiler.
I have to say, however, that i'd have rather seen an IDE that was capable of
analyzing the file, breaking the regions into virtual subsections(like
having a + in the treeview in solution explorer next to the file that drops
down into sub sections), properly decorated with class information, etc,
allowing for a developer to view the entire class, or subsections in a
virtual manner, without any distracting region labels, etc. without breaking
the files apart. If taken a step further it could potentially allow for far
greater flexibility than partial types would. Althought i'm sure that would
cause an increased amount of implementation complexity in the IDE (possibly
more than partial types adds to the compiler)

In a bit of defense, however, it would allow generators to (re)create entire
files without having to worry about wiping out user code, however why
merging the classes would have a benefit over inheriting from the generated
class is still a mystery to me.

 

[Fergus Cooney]

Hi Chad,

|| I still don't get the point of partial classes.

Some reasons why I look forward to them:

Regions are useful, but when I have to play clicky-clicky all the
time to hide and reveal it gets to be a real pain.

I can put these-definitely-work methods into one file,
these-are-getting-there into another and work-in-progress in another.
It all cuts down the amount of hunting and scrolling.

Search and replace is easier (more predictable) with a smaller
text base.

In a big class there will be logically distinct sections. I'd be
happier with these in separate files.

In a team situation, two members can work on the same class.

In a team situation, partial class files may be made read-only to
force a developer to pause and consider, or even have to seek
permission.

And I'm sure I've got more reasons waiting to be discovered.

Regards,
Fergus

 

[Fergus Cooney]

Hi Daniel,

I like your idea of the Explorer-style code window. Anything that
let's me see what I'm working on and hides the rest is welcome. I even
sometimes resent the single line that a hidden region takes (wastes) -
I'd like some other indicator (small, if not tiny).

But plenty of people don't use the IDE.

Regards,
Fergus

 

[Jon Skeet]

I know you've said this before, but I still don't
get the point of partial classes. From what I understand,
it's for situations like having Windows Forms designer
code in one file and all your implementation in another.

Is that really that big a of a deal with #region?

Absolutely! I've seen a number of classes which are part autogenerated,
part handwritten - and not just GUIs. Keeping the autogenerated parts
of those classes separate means that a change to the autogeneration
process (or whatever) can regenerate the autogenerated part without
disturbing the other part at all. Every change in the handwritten part
of the code is guaranteed to be done by a developer, so it's more
likely to be an interesting part of the history (where some
autogeneration tools might generate subtly different but functionally
equivalent code in multiple runs, eg the order of variables may be
different - that kind of thing isn't worth looking at).

 

[Harry Bosch]

Absolutely! I've seen a number of classes which are part autogenerated,
part handwritten - and not just GUIs. Keeping the autogenerated parts
of those classes separate means that a change to the autogeneration
process (or whatever) can regenerate the autogenerated part without
disturbing the other part at all. Every change in the handwritten part
of the code is guaranteed to be done by a developer, so it's more
likely to be an interesting part of the history (where some
autogeneration tools might generate subtly different but functionally
equivalent code in multiple runs, eg the order of variables may be
different - that kind of thing isn't worth looking at).

I've read two reasons in this thread that make some sense: 1) separating
out auto-generated code and 2) team development on a single class. I
could also understand code size management, but it hasn't been a problem
for me so far, and I suspect that a class that large should probably be
restructured. I'm not sure that any of these are so vitally important as
to require a change in the language.

But I think I am siding with the poster who voiced concern that the
feature will end up being abused, in ways we haven't envisioned. Take as
an example templates in C++. When they were first introduced, we thought
it was a nice way to make generic type-safe containers, and to avoid
having many overloaded functions of the same name (max(), for instance).
Now, C++ templates have grown into a complexity monster. I've used
templates for years, but I look at some of the code in boost or Loki, and
can only say "Huh?". I can't even read the stuff. I don't consider that
progress.

Part of the appeal of our "new" languages such as Java and C# is that
they got rid of the old-school mentality of complexity over usability.
Certainly not as satisfying to the ego, if you need that, but if you want
to write good, clean (and correct) code that both you and others can
understand, they were a great step in the right direction. As we have
seen with C and C++ over many years, abusing a feature cannot be
outlawed. The C preprocessor, templates, pointers and casts -- all
features that can be either used or abused, and which, mostly, are abused
by everyone simply because it's not illegal. It hardly matters that *I*,
as an individual developer, may not abuse them, because I don't work in a
vacuum and am constantly having to interface with code written by others,
including system libraries and SDKs as well as in-house code. And like a
disease, complexity infects everything it touches.

An additional benefit of that simplicity is the rapid growth of
programming aids and tools. Java has been around for a little while now,
and there are all kinds of programming tools that have sprung up. The
language is simple and clear enough that writing a code browser is not a
major undertaking requiring a team of 20 developers. C# is a little more
complex than Java, but still nowhere near C++ in complexity. Heck, I even
wrote a C# parser myself. It was more than an afternoon project on a
rainy day, but I did it. And I would never try writing a C++ parser!

Look: Visual Studio .NET 2002, right out of the gate, had immensely
better Class View and Intellisense than the same features for C++. Fast
and virtually bug-free. Same for the C# compiler. And yet, even in VS.NET
2003, after all these years of development, MS has not been able to get
Class View or the compiler to work correctly for C++ code. That should
tell us something. Will this be C# in 5 years?

I urge Microsoft not to turn C# and .NET into another COM embarrassment.
I know you have directives to churn out new features each year, but
please -- use caution, and focus on usability over complexity!

 

[Jon Skeet]

I've read two reasons in this thread that make some sense: 1) separating
out auto-generated code and 2) team development on a single class. I
could also understand code size management, but it hasn't been a problem
for me so far, and I suspect that a class that large should probably be
restructured.
Agreed.

I'm not sure that any of these are so vitally important as
to require a change in the language.

It's only a slight (and non-breaking, as I understand it) change, which
at least makes it easier to bear.

But I think I am siding with the poster who voiced concern that the
feature will end up being abused, in ways we haven't envisioned.

Oh I'm certainly *concerned* about that - but not necessarily to the
point of thinking it's a bad idea.

Fortunately, it's a feature which is *very* easily policed - the team
leader can much more easily search for abuses of this (as it should
rarely be used at all) than of things like C++ templates. That's part
of the reason for my tentative support - abuse of it is obvious.

 

[Harry Bosch]

It's only a slight (and non-breaking, as I understand it) change,
which at least makes it easier to bear.

Yes, non-breaking would make it agreeable Good point.

Fortunately, it's a feature which is *very* easily policed - the team
leader can much more easily search for abuses of this (as it should
rarely be used at all) than of things like C++ templates. That's part
of the reason for my tentative support - abuse of it is obvious.

Also agreed. I think my rant was more towards language directions in
general, and really really not wanting C# to head in that direction. I
think we're in good shape, however.