*** New C# Language V2.0 Specification Now Available ***

[Eric Gunnerson [MS]]

You may download the new specification at the C# Developer Center
(http://msdn.microsoft.com/vcsharp/language). There is a discussion forum
for the C# language on that same page.
If you don't own a copy of MS Word, you can download the free viewer at:

http://www.microsoft.com/downloads/d...displaylang=EN
--
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.

[Frans Bouma]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in
news:MP******** *************** *@msnews.micros oft.com:

Chris LaJoie <ch***@etriptra der.com> wrote:

> Partials are just stupid

I couldn't disagree more. In our project, we have a class that's
approaching 7000 lines of code. This gets to be a problem when we have
2 or 3 people who want to work on the file at the same time. It'd be
so much easier with partials.

That sounds like a really bad reason to use partial types, IMO. Is it
really not possible to refactor that code into more classes which would
increase the readability of the code to start with? I've only *very*
rarely seen classes which really deserve to be that long.

A class should be a logical element in the structure of the system.
Not a way to cut up code because a random person cooked up the idea that a
file of XYZ lines is too large. After all, cutting up a class in multiple
classes pollutes the class hierarchy with extra types that are hardly
different, creating extra problems when the types require each-others
data/logic (they were first stored in the same class, remember ;) ).

Although 7000 lines is a lot, you sometimes end up with large
classes, for example a main form class which controls all child windows
and main gui application logic (not the core application logic). It can
become very messy when you are chopping that up in smaller classes, which
will be used in just 1 spot: the main gui form, but because they're other
classes, you have add overhead code to communicate with them to reach
their data.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com

[Jon Skeet [C# MVP]]

Frans Bouma <pe************ ******@xs4all.n l> wrote:

That sounds like a really bad reason to use partial types, IMO. Is it
really not possible to refactor that code into more classes which would
increase the readability of the code to start with? I've only *very*
rarely seen classes which really deserve to be that long.
A class should be a logical element in the structure of the system.
Not a way to cut up code because a random person cooked up the idea that a
file of XYZ lines is too large. After all, cutting up a class in multiple
classes pollutes the class hierarchy with extra types that are hardly
different, creating extra problems when the types require each-others
data/logic (they were first stored in the same class, remember ;) ).

I agree that a class should be a logical element - but I've rarely seen
a single element of that many lines which isn't better broken down into
smaller subelements. That's not to say it should be done artificially,
of course.
Although 7000 lines is a lot, you sometimes end up with large
classes, for example a main form class which controls all child windows
and main gui application logic (not the core application logic). It can
become very messy when you are chopping that up in smaller classes, which
will be used in just 1 spot: the main gui form, but because they're other
classes, you have add overhead code to communicate with them to reach
their data.

If it controls *all* the child windows, I would have thought that would
be too much - each child window should have its own class, I'd imagine.
Maybe I'm misunderstandin g you though.

For what it's worth, I've been in a similar situation with all the GUI
logic for a mobile web application being in one class (this was written
a few years ago). Having started down that road, it's very difficult to
refactor it into smaller classes (we've tried twice). If we'd started
off with the goal of factoring out different parts, I'm sure it
wouldn't have been too difficult though. (One of the main problems was
that it was originally going to be a small app, and then it grew much,
much bigger.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[news.microsoft.com]

If you look at the BCLs you will see a huge deep inheratence tree. Also a
reason why we dont have multpile inheratance.

(never could spell that word too :D)

Im sure if you look more abstract at youre class you will see places you can
break it up or generalise and derive, try a little normalisation:D
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Frans Bouma <pe************ ******@xs4all.n l> wrote:

That sounds like a really bad reason to use partial types, IMO. Is it
really not possible to refactor that code into more classes which would increase the readability of the code to start with? I've only *very*
rarely seen classes which really deserve to be that long.

A class should be a logical element in the structure of the system.
Not a way to cut up code because a random person cooked up the idea that a file of XYZ lines is too large. After all, cutting up a class in multiple classes pollutes the class hierarchy with extra types that are hardly
different, creating extra problems when the types require each-others
data/logic (they were first stored in the same class, remember ;) ).

I agree that a class should be a logical element - but I've rarely seen
a single element of that many lines which isn't better broken down into
smaller subelements. That's not to say it should be done artificially,
of course.

Although 7000 lines is a lot, you sometimes end up with large
classes, for example a main form class which controls all child windows
and main gui application logic (not the core application logic). It can
become very messy when you are chopping that up in smaller classes, which will be used in just 1 spot: the main gui form, but because they're other classes, you have add overhead code to communicate with them to reach
their data.

If it controls *all* the child windows, I would have thought that would
be too much - each child window should have its own class, I'd imagine.
Maybe I'm misunderstandin g you though.

For what it's worth, I've been in a similar situation with all the GUI
logic for a mobile web application being in one class (this was written
a few years ago). Having started down that road, it's very difficult to
refactor it into smaller classes (we've tried twice). If we'd started
off with the goal of factoring out different parts, I'm sure it
wouldn't have been too difficult though. (One of the main problems was
that it was originally going to be a small app, and then it grew much,
much bigger.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Frans Bouma]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in
news:MP******** *************** *@msnews.micros oft.com:

Frans Bouma <pe************ ******@xs4all.n l> wrote:

Although 7000 lines is a lot, you sometimes end up with large
classes, for example a main form class which controls all child windows
and main gui application logic (not the core application logic). It can
become very messy when you are chopping that up in smaller classes,
which will be used in just 1 spot: the main gui form, but because
they're other classes, you have add overhead code to communicate with
them to reach their data.
If it controls *all* the child windows, I would have thought that would
be too much - each child window should have its own class, I'd imagine.
Maybe I'm misunderstandin g you though.

Child windows, for example in an MDI situation or docked inside the
main window, should control themselves, but say, the child window wants
something done in the application... where to put that logic, when yuo can
also start it from the menu for example... this will increase the main
form's code a lot and it's hard to chop it into multiple pieces because
you then end up with a lot of events, properties and other stuff that
wasn't even there in the beginning ;) exactly like you describe yourself:
For what it's worth, I've been in a similar situation with all the GUI
logic for a mobile web application being in one class (this was written
a few years ago). Having started down that road, it's very difficult to
refactor it into smaller classes (we've tried twice). If we'd started
off with the goal of factoring out different parts, I'm sure it
wouldn't have been too difficult though. (One of the main problems was
that it was originally going to be a small app, and then it grew much,
much bigger.)

That's what I ment :) But I agree that developers should write
classes that do a certain thing and not control the whole universe.
However it's sometimes hard to make the decision: add it to an existing
class or create a new class. Decisions like that in the early start of a
project can make the difference between a small set of large classes vs. a
large set of small classes.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com

[Jon Skeet [C# MVP]]

Frans Bouma <pe************ ******@xs4all.n l> wrote:

That's what I ment :) But I agree that developers should write
classes that do a certain thing and not control the whole universe.
However it's sometimes hard to make the decision: add it to an existing
class or create a new class. Decisions like that in the early start of a
project can make the difference between a small set of large classes vs. a
large set of small classes.

Absolutely - but I'd usually prefer a large set of small classes, and I
*really* don't think that encouraging a small set of large classes is
something the language specification ought to be doing.

The main use of partial classes as far as I can see, however, is
keeping the machine-generated parts away from the human-generated
parts. That seems a perfectly reasonable thing to encourage.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike Schilling]

Thanks, Eric. I don't suppose there's a list of changed sections anywhere,
or an MS Word diff tool I'm unaware of..

"Eric Gunnerson [MS]" <er****@online. microsoft.com> wrote in message
news:OD******** ******@TK2MSFTN GP10.phx.gbl...

The first two should be identical, though the ECMA one has different
numbering.
The third one has some clarifications and updates, and a new introduction.

--
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. "Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:eq******** ******@TK2MSFTN GP12.phx.gbl...

"Eric Gunnerson [MS]" <er****@online. microsoft.com> wrote in message
news:uh******** ******@TK2MSFTN GP09.phx.gbl...

You may download the new specification at the C# Developer Center
(http://msdn.microsoft.com/vcsharp/language). There is a discussion forum for the C# language on that same page.

I now have three C# language specs:

C# Language Specification (from Microsoft), dated 2001
ECMA-334, dated 2002
C# Language Specification v1.2, dated 2003

Where can I find descriptions of how they differ?

[cody]

> And as I recall, C\C++ reserved all names starting with __ or something to

that effect, so it was your fault if you screwed up, they told you
beforehand what not to use.

C++ added the keyword "mutable" (and others). There are no leading
underscores. I shit on breaking changes. The code is quickly corrected and
thats better than having to write ___mutable the next 30 years I use this
language!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Kevin Cline]

"Eric Gunnerson [MS]" <er****@online. microsoft.com> wrote in message news:<Oc******* *******@tk2msft ngp13.phx.gbl>. ..

--
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.
"cody" <do************ *********@gmx.d e> wrote in message
news:bn******** *****@ID-176797.news.uni-berlin.de...

Partials are just stupid

I have a bad feeling about them too but look into reality programming.

Often

Forms-classes can get really huge and now imagine you are working in a

team

and more than 1 programmer wants to work on that class. Additionally
automatically generated code can be separated from written code. Maybe

they

aren't as bad when you once get used to them-

The big goal for partial classes *is* for generated code. Being able to keep
that separate from the user code simpifies the user model.

Code generation is a work-around for bad languages and/or libraries.
If the language has sufficient power and libraries are well-designed
then there is little need to generate code. For example, you could
use Lex and YACC to generate C++ code, or you could use the SPIRIT
parser classes instead.

[Kerry Sanders]

>That sounds like a really bad reason to use partial types, IMO. Is it

really not possible to refactor that code into more classes which would
increase the readability of the code to start with? I've only *very*
rarely seen classes which really deserve to be that long.

I am not saying that there way of doing things is right or wrong. I can
definitely say I have written my share of crap code durin my 16 years a a
programmer, but I did hear someone say one time that if a class printout does
not fit on just one page, it is probably too long. :)

[Daniel O'Connell]

"cody" <do************ *********@gmx.d e> wrote in message
news:bn******** *****@ID-176797.news.uni-berlin.de...

And as I recall, C\C++ reserved all names starting with __ or something to that effect, so it was your fault if you screwed up, they told you
beforehand what not to use.
C++ added the keyword "mutable" (and others). There are no leading
underscores. I shit on breaking changes. The code is quickly corrected and
thats better than having to write ___mutable the next 30 years I use this
language!

Well, when it comes down to it, thats your problem. You are really far to
rude to actually achieve anything. But, anyway, adding a keyword when it has
to be added is one thing, in this case its not, no matter how much you want
to complain about it. --
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk