Jon Skeet <sk***@pobox.com> wrote:
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!
--
harry