Simple question about complicated questions about Generics.

[Michael S]

Why do people spend so much time writing complex generic types?

for fun?
to learn?
for use?

I think of generics like I do about operator overloading.
Great to have as a language-feature, as it defines the language more
completely. Great to use.

But code one?

While I love to use generic classes; I seldom need to code my own.
How often do you guys code your own generic classes? why? what for?

Seriously Asking
- Michael S

[Rene]

I think the answer to you question depends on how much knowledge about
Generics a person has.

A person with limited Generics knowledge will probably not use Generics that
often but a person that has digged deep into the whys and how's about
Generics will probably be able to leverage all that knowledge and apply
Generics into scenarios that most people didn't even know was possible.

There's a book called "Profession al .Net 2.0 Generics" by Wrox, read it from
cover to cover and take the time to play around with the examples to fully
understand what's going on and realize the potential on Generics. After
that, maybe you will start using Generics far more than what you are doing
now!!

Have a good day.

[Jon Skeet [C# MVP]]

Rene <no****@nospam. com> wrote:

I think the answer to you question depends on how much knowledge about
Generics a person has.

A person with limited Generics knowledge will probably not use Generics that
often but a person that has digged deep into the whys and how's about
Generics will probably be able to leverage all that knowledge and apply
Generics into scenarios that most people didn't even know was possible.

There's a book called "Profession al .Net 2.0 Generics" by Wrox, read it from
cover to cover and take the time to play around with the examples to fully
understand what's going on and realize the potential on Generics. After
that, maybe you will start using Generics far more than what you are doing
now!!

That may not be a good thing, of course. There are lots of things which
*can* be done in generics but could also be done more simply without
generics.

I'm not suggesting that generics are a bad thing by any means - just
that they can be overused simply because a developer knows them and
wants to play with fun new technology.

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

[Christoph Nahr]

On Thu, 29 Dec 2005 03:22:15 +0100, "Michael S" <[e-mail]> wrote:

Why do people spend so much time writing complex generic types?
Um, what people? Who or what are you talking about?
How often do you guys code your own generic classes? why? what for?

For my own custom collection classes, and utility methods that operate
on generic collections. Also, for events that take a single argument
of an arbitrary type. That's it, basically...
--
http://www.kynosarges.de

[Joanna Carter [TeamB]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> a écrit dans le message de news:
MP************* ***********@msn ews.microsoft.c om...

| That may not be a good thing, of course. There are lots of things which
| *can* be done in generics but could also be done more simply without
| generics.
|
| I'm not suggesting that generics are a bad thing by any means - just
| that they can be overused simply because a developer knows them and
| wants to play with fun new technology.

This is exactly the scenario that we found ourselves in. We had a definite
requirement for a few generic classes, but then we found that we tended to
automatically try to use generic classes for everything.

I think generics should be used in the same way as inheritance :

Instead of designing a super-class and then trying to derive from it, you
should always design separate classes and only when you start to recognise
commonality, extract the super-class.

So with generics, you should start by designing separate typed classes and
then, if their behaviour is truly identical, replace them with a generic
type.

I have written an article on using generics in Design Patterns for the UK
Developers Group magazine which demonstrates this principle and which is
available at http://www.prototypical.co.uk/pdf/visitor.pdf

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Rick Elbers]

Joanna,

Sorry to say. Bad advise both on parametrized classes as well as
on Inheritance.

On Thu, 29 Dec 2005 10:40:28 -0000, "Joanna Carter [TeamB]"
<jo****@not.for .spam> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.co m> a écrit dans le message de news:
MP************ ************@ms news.microsoft. com...

| That may not be a good thing, of course. There are lots of things which
| *can* be done in generics but could also be done more simply without
| generics.
|
| I'm not suggesting that generics are a bad thing by any means - just
| that they can be overused simply because a developer knows them and
| wants to play with fun new technology.

This is exactly the scenario that we found ourselves in. We had a definite
requirement for a few generic classes, but then we found that we tended to
automaticall y try to use generic classes for everything.

I think generics should be used in the same way as inheritance :

Instead of designing a super-class and then trying to derive from it, you
should always design separate classes and only when you start to recognise
commonality, extract the super-class.
Surely code bloat and absurd design will result. Bottom up design is
famous for bad decisions. Let alone that "commonalit y" isnt even
exactly defined. Use of the ADT approach is widely considered
superior, and indeed that starts off with abstract AND related
"superclass es" or interfaces. Thats far better then relate all kind of
concrete classes and then refactor into some kind of hierarchie.

There will never be a good framework without good abstract concepts
definied into abstract classes and/or interfaces.

So with generics, you should start by designing separate typed classes and
then, if their behaviour is truly identical, replace them with a generic
type.

Absurd. If you understand the parametrization and its forces.
I have written an article on using generics in Design Patterns for the UK
Developers Group magazine which demonstrates this principle and which is
available at http://www.prototypical.co.uk/pdf/visitor.pdf

very good generics beginners article Joanna. It has imho not a lot to
do with the proffesional way of using parametrized classes though. The
visitor pattern and all its parent double dispatchers is already
something very obscure and not often used, let alone some absurd
trivial ValueType class.

Proffesional use of generics will mostly be valuable by people wrting
framework code to be used by others. They will know and understand
the use as they will do with inheritance and delegation because they
have to do design. If we are talking people who just code away custom
apps with 1 user or buyer, then they will not benifit from no generic
code( that is coding towards abstractions implemented in c# with
interfaces, abstract classes, inheritance and generics). Most people
seem to use c# as vb, but some are using it like c/c++ and they will
fully appreciate the generics..

For really strong examples you probably should look into delegates
and other observer implementations and in abstract factories instead
of the OO defeating visitorpattern.
Joanna

Rick

[Joanna Carter [TeamB]]

"Rick Elbers" <ri*********@ch ello.nl> a écrit dans le message de news:
6a************* *************** ****@4ax.com...

| Sorry to say. Bad advise both on parametrized classes as well as
| on Inheritance.

In your opinion maybe.

| Surely code bloat and absurd design will result.

Well, it never has over the past ten or so years for me.

| Bottom up design is
| famous for bad decisions. Let alone that "commonalit y" isnt even
| exactly defined. Use of the ADT approach is widely considered
| superior, and indeed that starts off with abstract AND related
| "superclass es" or interfaces. Thats far better then relate all kind of
| concrete classes and then refactor into some kind of hierarchie.

Not in my experience.

| There will never be a good framework without good abstract concepts
| definied into abstract classes and/or interfaces.

Correct, but that doesn't mean that you have to design the abstract classes
before the concrete ones.

| >So with generics, you should start by designing separate typed classes
and
| >then, if their behaviour is truly identical, replace them with a generic
| >type.
|
| Absurd. If you understand the parametrization and its forces.

Well, I have had no problems.

| very good generics beginners article Joanna. It has imho not a lot to
| do with the proffesional way of using parametrized classes though. The
| visitor pattern and all its parent double dispatchers is already
| something very obscure and not often used, let alone some absurd
| trivial ValueType class.

You seem to think a lot of things are absurd :-) The ValueType class is a
real world example of a metadata-rich framework for object persistence and
UI presentation of objects.

| Proffesional use of generics will mostly be valuable by people wrting
| framework code to be used by others. They will know and understand
| the use as they will do with inheritance and delegation because they
| have to do design.

Frameworks form a large part of my work, which is why I have found so much
use for generics

| Most people
| seem to use c# as vb, but some are using it like c/c++ and they will
| fully appreciate the generics..

Coming from a C/C++/Delphi background, I can't really say what a VB
programmer thinks of C#. I find it a very nice Cesque version of Delphi;
capable of most things from drag and drop RAD development right through to
complex fully OO model driven frameworks and utilities.

| For really strong examples you probably should look into delegates
| and other observer implementations and in abstract factories instead
| of the OO defeating visitorpattern.

The article was the first in a series of articles on design patterns in C#
using generics; other articles cover things like the Observer pattern and
other patterns.

I find your comment that the Visitor pattern is OO defeating quite odd, as
it is a pattern that allows you to maintain the integrity of a hierarchy
whilst adding common behaviour throughout the hierarchy in a type specific
manner.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[kevin cline]

I use the generics when I want to factor out duplicated code, and the
duplicated bits have some variation on type.

Many times I wish that C# generics were more powerful. For example, I
would like to write code like this, which takes a boolean function and
returns a new function returning the opposite value of the original:

delegate bool Predicate<T>(T arg);

Predicate<T> Not<T>(Predicat e<T> f)
{
return new Predicate<T>(de legate(T t) { return !f(t); } )
}

[Michael S]

"Rick Elbers" <ri*********@ch ello.nl> wrote in message
news:6a******** *************** *********@4ax.c om...

Joanna,

Sorry to say. Bad advise both on parametrized classes as well as
on Inheritance.

On Thu, 29 Dec 2005 10:40:28 -0000, "Joanna Carter [TeamB]"
<jo****@not.for .spam> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.co m> a écrit dans le message de news:
MP*********** *************@m snews.microsoft .com...

| That may not be a good thing, of course. There are lots of things which
| *can* be done in generics but could also be done more simply without
| generics.
A truism! A lot of words but no content...
| I'm not suggesting that generics are a bad thing by any means - just
| that they can be overused simply because a developer knows them and
| wants to play with fun new technology.

This is exactly the scenario that we found ourselves in. We had a definite
requirement for a few generic classes, but then we found that we tended to
automatical ly try to use generic classes for everything.
This is exactly whats going to happen if you let a couple of geeks decide
architecture.

I think generics should be used in the same way as inheritance :

Instead of designing a super-class and then trying to derive from it, you
should always design separate classes and only when you start to recognise
commonality , extract the super-class.
Oh, you been at school? Did you score well? Why should you 'always' do
stuff?

Surely code bloat and absurd design will result. Bottom up design is
famous for bad decisions. Let alone that "commonalit y" isnt even
exactly defined. Use of the ADT approach is widely considered
superior, and indeed that starts off with abstract AND related
"superclass es" or interfaces. Thats far better then relate all kind of
concrete classes and then refactor into some kind of hierarchie.

There will never be a good framework without good abstract concepts
definied into abstract classes and/or interfaces.

So with generics, you should start by designing separate typed classes and
then, if their behaviour is truly identical, replace them with a generic
type.

Should we? I think not. I would like for you to combine 'time/money' and
'experience' into this. Did you copy this from a textbook? What was their
point? Do you have any ideas of your own?

Absurd. If you understand the parametrization and its forces.

I have written an article on using generics in Design Patterns for the UK
Developers Group magazine which demonstrates this principle and which is
available at http://www.prototypical.co.uk/pdf/visitor.pdf

very good generics beginners article Joanna. It has imho not a lot to
do with the proffesional way of using parametrized classes though. The
visitor pattern and all its parent double dispatchers is already
something very obscure and not often used, let alone some absurd
trivial ValueType class.

Beginners? Are you that clueless? Joanna Carter more or less set the stage
for MVC and are a major spirit in anything revolving OO. Tjeesus!

Proffesional use of generics will mostly be valuable by people wrting
framework code to be used by others. They will know and understand
the use as they will do with inheritance and delegation because they
have to do design. If we are talking people who just code away custom
apps with 1 user or buyer, then they will not benifit from no generic
code( that is coding towards abstractions implemented in c# with
interfaces, abstract classes, inheritance and generics). Most people
seem to use c# as vb, but some are using it like c/c++ and they will
fully appreciate the generics..

For really strong examples you probably should look into delegates
and other observer implementations and in abstract factories instead
of the OO defeating visitorpattern.

Joanna

Rick

While I think Joanna is somewhat way too 'model', like dear mr. Skeet, for
my taste, at least they known what their doing...

Happy<T>
- Michael S

[Michael S]

"kevin cline" <ke*********@gm ail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

I use the generics when I want to factor out duplicated code, and the
duplicated bits have some variation on type.

Many times I wish that C# generics were more powerful. For example, I
would like to write code like this, which takes a boolean function and
returns a new function returning the opposite value of the original:

delegate bool Predicate<T>(T arg);

Predicate<T> Not<T>(Predicat e<T> f)
{
return new Predicate<T>(de legate(T t) { return !f(t); } )
}

Will C#3 solve this? Make it easier?
Jon, Nicholas? Any thoughts.....