By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,635 Members | 2,227 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,635 IT Pros & Developers. It's quick & easy.

Simple question about complicated questions about Generics.

P: n/a
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



Dec 29 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
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 "Professional .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.
Dec 29 '05 #2

P: n/a
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 "Professional .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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 29 '05 #3

P: n/a
On Thu, 29 Dec 2005 03:22:15 +0100, "Michael S" <no@mail.com> 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
Dec 29 '05 #4

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.com> a écrit dans le message de news:
MP************************@msnews.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
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
Dec 29 '05 #5

P: n/a
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.com> a écrit dans le message de news:
MP************************@msnews.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
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.
Surely code bloat and absurd design will result. Bottom up design is
famous for bad decisions. Let alone that "commonality" isnt even
exactly defined. Use of the ADT approach is widely considered
superior, and indeed that starts off with abstract AND related
"superclasses" 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

Dec 29 '05 #6

P: n/a
"Rick Elbers" <ri*********@chello.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 "commonality" isnt even
| exactly defined. Use of the ADT approach is widely considered
| superior, and indeed that starts off with abstract AND related
| "superclasses" 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
Dec 29 '05 #7

P: n/a
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>(Predicate<T> f)
{
return new Predicate<T>(delegate(T t) { return !f(t); } )
}

Dec 30 '05 #8

P: n/a

"Rick Elbers" <ri*********@chello.nl> wrote in message
news:6a********************************@4ax.com...
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.com> a écrit dans le message de news:
MP************************@msnews.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
automatically 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 "commonality" isnt even
exactly defined. Use of the ADT approach is widely considered
superior, and indeed that starts off with abstract AND related
"superclasses" 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
Dec 30 '05 #9

P: n/a
"kevin cline" <ke*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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>(Predicate<T> f)
{
return new Predicate<T>(delegate(T t) { return !f(t); } )
}


Will C#3 solve this? Make it easier?
Jon, Nicholas? Any thoughts.....
Dec 30 '05 #10

P: n/a
I hope so, because as it stands C# does not support functional
programming in any type-safe manner.

Dec 30 '05 #11

P: n/a
And so we realize that "Michael S" is in fact an idiot troll who
should be ignored.
--
http://www.kynosarges.de
Dec 30 '05 #12

P: n/a
kevin cline <ke*********@gmail.com> wrote:
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>(Predicate<T> f)
{
return new Predicate<T>(delegate(T t) { return !f(t); } )
}


You mean like this?

using System;

public class Test
{
delegate bool Predicate<T>(T arg);

static Predicate<T> Not<T>(Predicate<T> f)
{
return new Predicate<T>(delegate(T t) { return !f(t); } );
}

static void Main()
{
Predicate<string> len = delegate(string x)
{ return x.Length > 5; };

Predicate<string> notLen = Not(len);

Console.WriteLine (len("Hello there"));
Console.WriteLine (notLen("Hello there"));
}
}

There *are* limitations of generics, but this isn't one of them :)

See http://msmvps.com/blogs/jon.skeet/ar.../29/68189.aspx for
a similar example. The problem is that while you can declare a generic
method and return Not<T> from it, you can't do the same "inline" in
code.

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

This discussion thread is closed

Replies have been disabled for this discussion.