Does Microsoft even bother involving developers anymore in their process of
developing new "features"?

I've spent about four hours with VS2005 now and can't believe the list of
problematic improvements I've generated in that short time.

Then I run across this partial class feature. What a mind bending stupid
idea. This isn't an object oriented concept at all - it's very much akin to
using a preprocessor to insert code.

The ability to "hide" code is pretty much covered by the OO model - it's
called encapsulation. Hiding UI code is the reason given for this
"innovation". What happened to patterns such as MVC? Even a UI helper class
would be a better idea. UI code could have been placed in a generated class
which is then included as a member in the developer's "business" logic class.
At least there would be a clear separation of function with this approach.

Splitting code for a single class into multiple files is such an obvious,
bad, hack. It seems to me the last resort to solving a programming problem is
to change the underlying language specification. What a horrible precedent
to set. Microsoft language "architects" ought to be really ashamed of
themselves for permitting this feature to be added to the .Net language
syntax.

IMHO,
Mike O'Shea
Logicalis

Re: Partial classes not good OO design by Barry

Barry
Wed May 10 22:30:50 CDT 2006

oshea00 <oshea00@discussions.microsoft.com> wrote:

> Then I run across this partial class feature. What a mind bending stupid
> idea. This isn't an object oriented concept at all - it's very much akin to
> using a preprocessor to insert code.

It's totally about hiding the code generated by machines, it isn't
really for human use. One problem with using inheritance for this
specific purpose is that the human driving the process may want some
generated members may be private, and thus they wouldn't be accessible
using other techniques.

-- Barry

Re: Partial classes not good OO design by oshea00

oshea00
Wed May 10 23:53:05 CDT 2006

Thanks Barry. The problem with the solution is that it's now a language
feature that can be used for other purposes than hiding machine generated
code. It creates more problems than the one it was intended to solve.

The machine generated code could have been placed in a separate class (where
the private machine generated methods would have relevance) and included as a
member in the "user friendly" class representing the Form.

So, there would be one declaration in the user friendly class that could be
accidentally deleted - a problem easily fixed by adding a check at build time
that could replace the missing line or provide a build error message. But not
much more than that could be done unless the coder wanted to track down the
generated class file and make changes to it directly.

Well, even with the partial class solution, nothing prevents the coder from
editing the generated partial class file. Using the more OO approach above
wouldn't prevent the coder from editing the generated class either - at least
it doesn't require a language spec change on top of everything else.

See what I mean? The "solution" doesn't even solve the problem better than
using a more OO approach already supported by the language.

That's what I'm whining about.

"Barry Kelly" wrote:

> oshea00 <oshea00@discussions.microsoft.com> wrote:
>
> > Then I run across this partial class feature. What a mind bending stupid
> > idea. This isn't an object oriented concept at all - it's very much akin to
> > using a preprocessor to insert code.
>
> It's totally about hiding the code generated by machines, it isn't
> really for human use. One problem with using inheritance for this
> specific purpose is that the human driving the process may want some
> generated members may be private, and thus they wouldn't be accessible
> using other techniques.
>
> -- Barry
>

Re: Partial classes not good OO design by Mattias

Mattias
Thu May 11 00:36:10 CDT 2006

>>Does Microsoft even bother involving developers anymore in their process of
>>developing new "features"?

There were various preview and beta builds of VS2005 released years
before it finally shipped. And during that time, I can't recall ever
seeing anyone complaining about this aspect of partial classes. I
think you're the first.


>>Then I run across this partial class feature. What a mind bending stupid
>>idea. This isn't an object oriented concept at all - it's very much akin to
>>using a preprocessor to insert code.

Is that a bad thing? Does every feature necessarily be based on OO to
be useful? Why whould your physical source code distribution have
anything to do with OO?


>>Splitting code for a single class into multiple files is such an obvious,
>>bad, hack.

Other languages such as C++ has supported this for years. Do you think
C++ is a hack too?


>Thanks Barry. The problem with the solution is that it's now a language
>feature that can be used for other purposes than hiding machine generated
>code.

Almost any feature can be abused, that doesn't necessarily make it bad
when used appropriately.


>It creates more problems than the one it was intended to solve.

What problems do partial classes create?


Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Re: Partial classes not good OO design by Kevin

Kevin
Thu May 11 07:24:22 CDT 2006

Let me see if I get this straight. You're complaining that an *additional
feature,* which, if used correctly, can make the development process much
simpler, is a problem because people can abuse it? Hmm. Perhaps we ought to
apply that to any feature that a developer can abuse. Of course, it we did,
there would be no programming technologies, languages, or developers.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"oshea00" <oshea00@discussions.microsoft.com> wrote in message
news:5D06C446-F90D-4304-93BB-BE7BA7834354@microsoft.com...
> Thanks Barry. The problem with the solution is that it's now a language
> feature that can be used for other purposes than hiding machine generated
> code. It creates more problems than the one it was intended to solve.
>
> The machine generated code could have been placed in a separate class
> (where
> the private machine generated methods would have relevance) and included
> as a
> member in the "user friendly" class representing the Form.
>
> So, there would be one declaration in the user friendly class that could
> be
> accidentally deleted - a problem easily fixed by adding a check at build
> time
> that could replace the missing line or provide a build error message. But
> not
> much more than that could be done unless the coder wanted to track down
> the
> generated class file and make changes to it directly.
>
> Well, even with the partial class solution, nothing prevents the coder
> from
> editing the generated partial class file. Using the more OO approach
> above
> wouldn't prevent the coder from editing the generated class either - at
> least
> it doesn't require a language spec change on top of everything else.
>
> See what I mean? The "solution" doesn't even solve the problem better
> than
> using a more OO approach already supported by the language.
>
> That's what I'm whining about.
>
> "Barry Kelly" wrote:
>
>> oshea00 <oshea00@discussions.microsoft.com> wrote:
>>
>> > Then I run across this partial class feature. What a mind bending
>> > stupid
>> > idea. This isn't an object oriented concept at all - it's very much
>> > akin to
>> > using a preprocessor to insert code.
>>
>> It's totally about hiding the code generated by machines, it isn't
>> really for human use. One problem with using inheritance for this
>> specific purpose is that the human driving the process may want some
>> generated members may be private, and thus they wouldn't be accessible
>> using other techniques.
>>
>> -- Barry
>>



Re: Partial classes not good OO design by Michael

Michael
Thu May 11 07:52:51 CDT 2006


There is absoluteley NOTHING in the OO paradigm that requires class code be
limited to a single source file. The real question is whether the interface
to the class is secure in that consumers of the class cannot see the
implementation details of the class. Implicit inheritance, by exposing some
of the underlying implementation, is more of a problem in this regard than
splitting the class source across multiple files. Both features, when used
correctly, can improve code and ease of maintainence. Both features, when
used incorrectly, can become the OO paradigm's equivalent to unstructured
GOTOs.

Mike Ober.

"oshea00" <oshea00@discussions.microsoft.com> wrote in message
news:6768E210-0C7B-4F10-BD76-6F32931ABDDC@microsoft.com...
> Does Microsoft even bother involving developers anymore in their process
of
> developing new "features"?
>
> I've spent about four hours with VS2005 now and can't believe the list of
> problematic improvements I've generated in that short time.
>
> Then I run across this partial class feature. What a mind bending stupid
> idea. This isn't an object oriented concept at all - it's very much akin
to
> using a preprocessor to insert code.
>
> The ability to "hide" code is pretty much covered by the OO model - it's
> called encapsulation. Hiding UI code is the reason given for this
> "innovation". What happened to patterns such as MVC? Even a UI helper
class
> would be a better idea. UI code could have been placed in a generated
class
> which is then included as a member in the developer's "business" logic
class.
> At least there would be a clear separation of function with this
approach.
>
> Splitting code for a single class into multiple files is such an obvious,
> bad, hack. It seems to me the last resort to solving a programming problem
is
> to change the underlying language specification. What a horrible
precedent
> to set. Microsoft language "architects" ought to be really ashamed of
> themselves for permitting this feature to be added to the .Net language
> syntax.
>
> IMHO,
> Mike O'Shea
> Logicalis
>
>
>




Re: Partial classes not good OO design by Paul

Paul
Thu May 11 07:58:51 CDT 2006

What I tend to dislike about it (well more the concept) is that it seems to
have only been included to work with Visual Studio! I don't think anything
should be included in a language just to make the editor work (or work
better / worse depending upon your opinion)

- Paul.

"oshea00" <oshea00@discussions.microsoft.com> wrote in message
news:5D06C446-F90D-4304-93BB-BE7BA7834354@microsoft.com...
> Thanks Barry. The problem with the solution is that it's now a language
> feature that can be used for other purposes than hiding machine generated
> code. It creates more problems than the one it was intended to solve.
>
> The machine generated code could have been placed in a separate class
> (where
> the private machine generated methods would have relevance) and included
> as a
> member in the "user friendly" class representing the Form.
>
> So, there would be one declaration in the user friendly class that could
> be
> accidentally deleted - a problem easily fixed by adding a check at build
> time
> that could replace the missing line or provide a build error message. But
> not
> much more than that could be done unless the coder wanted to track down
> the
> generated class file and make changes to it directly.
>
> Well, even with the partial class solution, nothing prevents the coder
> from
> editing the generated partial class file. Using the more OO approach
> above
> wouldn't prevent the coder from editing the generated class either - at
> least
> it doesn't require a language spec change on top of everything else.
>
> See what I mean? The "solution" doesn't even solve the problem better
> than
> using a more OO approach already supported by the language.
>
> That's what I'm whining about.
>
> "Barry Kelly" wrote:
>
>> oshea00 <oshea00@discussions.microsoft.com> wrote:
>>
>> > Then I run across this partial class feature. What a mind bending
>> > stupid
>> > idea. This isn't an object oriented concept at all - it's very much
>> > akin to
>> > using a preprocessor to insert code.
>>
>> It's totally about hiding the code generated by machines, it isn't
>> really for human use. One problem with using inheritance for this
>> specific purpose is that the human driving the process may want some
>> generated members may be private, and thus they wouldn't be accessible
>> using other techniques.
>>
>> -- Barry
>>



Re: Partial classes not good OO design by Michael

Michael
Thu May 11 08:42:02 CDT 2006


Partial classes also solve the issue of mixing code and UI elements in
web-projects.

Mike.

"Paul" <nonone@noone.com> wrote in message
news:%232k6TuPdGHA.4892@TK2MSFTNGP02.phx.gbl...
>
> What I tend to dislike about it (well more the concept) is that it seems
to
> have only been included to work with Visual Studio! I don't think anything
> should be included in a language just to make the editor work (or work
> better / worse depending upon your opinion)
>
> - Paul.
>
> "oshea00" <oshea00@discussions.microsoft.com> wrote in message
> news:5D06C446-F90D-4304-93BB-BE7BA7834354@microsoft.com...
> > Thanks Barry. The problem with the solution is that it's now a language
> > feature that can be used for other purposes than hiding machine
generated
> > code. It creates more problems than the one it was intended to solve.
> >
> > The machine generated code could have been placed in a separate class
> > (where
> > the private machine generated methods would have relevance) and included
> > as a
> > member in the "user friendly" class representing the Form.
> >
> > So, there would be one declaration in the user friendly class that could
> > be
> > accidentally deleted - a problem easily fixed by adding a check at build
> > time
> > that could replace the missing line or provide a build error message.
But
> > not
> > much more than that could be done unless the coder wanted to track down
> > the
> > generated class file and make changes to it directly.
> >
> > Well, even with the partial class solution, nothing prevents the coder
> > from
> > editing the generated partial class file. Using the more OO approach
> > above
> > wouldn't prevent the coder from editing the generated class either - at
> > least
> > it doesn't require a language spec change on top of everything else.
> >
> > See what I mean? The "solution" doesn't even solve the problem better
> > than
> > using a more OO approach already supported by the language.
> >
> > That's what I'm whining about.
> >
> > "Barry Kelly" wrote:
> >
> >> oshea00 <oshea00@discussions.microsoft.com> wrote:
> >>
> >> > Then I run across this partial class feature. What a mind bending
> >> > stupid
> >> > idea. This isn't an object oriented concept at all - it's very much
> >> > akin to
> >> > using a preprocessor to insert code.
> >>
> >> It's totally about hiding the code generated by machines, it isn't
> >> really for human use. One problem with using inheritance for this
> >> specific purpose is that the human driving the process may want some
> >> generated members may be private, and thus they wouldn't be accessible
> >> using other techniques.
> >>
> >> -- Barry
> >>
>
>
>




Re: Partial classes not good OO design by kh

kh
Fri May 12 03:01:02 CDT 2006

any code generator can now make use of this feature, including ones you write
yourself. code generators can significantly enhance developer productivity
and any language feature which helps support them is a good thing. i agree
that language evolution should not necessarily be driven by the associated
toolset, but language designers cannot ignore the needs of commercial
developers with regards to productivity.




Re: Partial classes not good OO design by Jay

Jay
Fri May 12 07:27:52 CDT 2006

Paul,
You are free to introduce your own partial classes. See partial in VB or C#.

Of course like any language feature it is easy to abuse. As Kevin suggests,
just because you can abuse something doesn't mean its bad. Look at multiple
inheritance in the languages that support it, its been known to be over used
& abused. That doesn't mean that MI is bad where you should use...

In fact they (partial classes) are rather useful in typed datasets, VB My
Settings, Resources... Any generated class that you want to add code to.

Even non-generated classes they can be useful for organization reasons:

I use them to separate nested classes into their own files.

' SomeCollection.vb
Public Class SomeCollection
...
End Class

' SomeCollection.Enumerator.vb
Partial Public Class SomeCollection
Private Class Enumerator
...
End Class
End Class

I also use them to separate out interface implementations that are required
in a specific class.

I've used them in VSTO projects to help organize code.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


"Paul" <nonone@noone.com> wrote in message
news:%232k6TuPdGHA.4892@TK2MSFTNGP02.phx.gbl...
| What I tend to dislike about it (well more the concept) is that it seems
to
| have only been included to work with Visual Studio! I don't think anything
| should be included in a language just to make the editor work (or work
| better / worse depending upon your opinion)
|
| - Paul.
|
| "oshea00" <oshea00@discussions.microsoft.com> wrote in message
| news:5D06C446-F90D-4304-93BB-BE7BA7834354@microsoft.com...
| > Thanks Barry. The problem with the solution is that it's now a language
| > feature that can be used for other purposes than hiding machine
generated
| > code. It creates more problems than the one it was intended to solve.
| >
| > The machine generated code could have been placed in a separate class
| > (where
| > the private machine generated methods would have relevance) and included
| > as a
| > member in the "user friendly" class representing the Form.
| >
| > So, there would be one declaration in the user friendly class that could
| > be
| > accidentally deleted - a problem easily fixed by adding a check at build
| > time
| > that could replace the missing line or provide a build error message.
But
| > not
| > much more than that could be done unless the coder wanted to track down
| > the
| > generated class file and make changes to it directly.
| >
| > Well, even with the partial class solution, nothing prevents the coder
| > from
| > editing the generated partial class file. Using the more OO approach
| > above
| > wouldn't prevent the coder from editing the generated class either - at
| > least
| > it doesn't require a language spec change on top of everything else.
| >
| > See what I mean? The "solution" doesn't even solve the problem better
| > than
| > using a more OO approach already supported by the language.
| >
| > That's what I'm whining about.
| >
| > "Barry Kelly" wrote:
| >
| >> oshea00 <oshea00@discussions.microsoft.com> wrote:
| >>
| >> > Then I run across this partial class feature. What a mind bending
| >> > stupid
| >> > idea. This isn't an object oriented concept at all - it's very much
| >> > akin to
| >> > using a preprocessor to insert code.
| >>
| >> It's totally about hiding the code generated by machines, it isn't
| >> really for human use. One problem with using inheritance for this
| >> specific purpose is that the human driving the process may want some
| >> generated members may be private, and thus they wouldn't be accessible
| >> using other techniques.
| >>
| >> -- Barry
| >>
|
|



Re: Partial classes not good OO design by Marina

Marina
Fri May 12 11:00:00 CDT 2006

In addtion to what some of the others has said, I believe partial classes
allow some other language features to be possible. I don't remember the
details now, but I believe the LINQ project is possible to implement due to
partial classes. I don't think partial classes were added only to allow
the designer to put code in a separate file.

"oshea00" <oshea00@discussions.microsoft.com> wrote in message
news:6768E210-0C7B-4F10-BD76-6F32931ABDDC@microsoft.com...
> Does Microsoft even bother involving developers anymore in their process
> of
> developing new "features"?
>
> I've spent about four hours with VS2005 now and can't believe the list of
> problematic improvements I've generated in that short time.
>
> Then I run across this partial class feature. What a mind bending stupid
> idea. This isn't an object oriented concept at all - it's very much akin
> to
> using a preprocessor to insert code.
>
> The ability to "hide" code is pretty much covered by the OO model - it's
> called encapsulation. Hiding UI code is the reason given for this
> "innovation". What happened to patterns such as MVC? Even a UI helper
> class
> would be a better idea. UI code could have been placed in a generated
> class
> which is then included as a member in the developer's "business" logic
> class.
> At least there would be a clear separation of function with this approach.
>
> Splitting code for a single class into multiple files is such an obvious,
> bad, hack. It seems to me the last resort to solving a programming problem
> is
> to change the underlying language specification. What a horrible
> precedent
> to set. Microsoft language "architects" ought to be really ashamed of
> themselves for permitting this feature to be added to the .Net language
> syntax.
>
> IMHO,
> Mike O'Shea
> Logicalis
>
>