Is this a reasonable way to use generics?

[J.Marsch]

All:

I have an interesting problem in front of me. does this sound reasonable,
or ridiculous?

I have to build something that is sort of like a style sheet for Windows
controls.
Picture a collection of dissimilar value types: a couple of Color types,
some ints, some strings etc.

I _could_ just use a hashtable of object to contain all of these, but since
they are value types, they would be boxed.

But what if I did this: (warning the syntax probably isn't spot on)
public class Element<T>
{
public T Value;
public Element(T value)
{
this.Value = value;
}
}

And then stored the element objects in my collection:
So, here is how I would store a couple of properties:
{
HashTable styleElements = new HashTable();
styleElements.Add("BackgroundColor", new Element<Color>(Color.Blue);
styleElements.Add("FontName", new Element<string>("Arial");
// and so on

//now accessing the collection:
aControl.BackgroundColor =
((Element<Color>)styleElements["BackgroundColor"]).Value;
}

Is this a horrible, horrible idea, or is it preferable to directly storing
the value types in the hashtable (thereby boxing them)?

[Luc E. Mistiaen]

It seems to me that you just made the boxing explicit (and probably less
efficient than the implicit one).

/LM

"J.Marsch" <jm*****@newsgroup.nospam> wrote in message
news:ey**************@tk2msftngp13.phx.gbl...

All:

I have an interesting problem in front of me. does this sound reasonable,
or ridiculous?

I have to build something that is sort of like a style sheet for Windows
controls.
Picture a collection of dissimilar value types: a couple of Color types,
some ints, some strings etc.

I _could_ just use a hashtable of object to contain all of these, but
since they are value types, they would be boxed.

But what if I did this: (warning the syntax probably isn't spot on)
public class Element<T>
{
public T Value;
public Element(T value)
{
this.Value = value;
}
}

And then stored the element objects in my collection:
So, here is how I would store a couple of properties:
{
HashTable styleElements = new HashTable();
styleElements.Add("BackgroundColor", new Element<Color>(Color.Blue);
styleElements.Add("FontName", new Element<string>("Arial");
// and so on

//now accessing the collection:
aControl.BackgroundColor =
((Element<Color>)styleElements["BackgroundColor"]).Value;
}

Is this a horrible, horrible idea, or is it preferable to directly storing
the value types in the hashtable (thereby boxing them)?

[J.Marsch]

Hmm. Looking back, I don't know whether I am much more efficient than
boxing, as I am now manually allocating a new class (the element), so there
is still an additional heap allocation.

But I want to get back to your comments about explicitly vs. implicitely
boxing. It was my understanding that if you pass a value type as the
parameter to a generic type, then you get a "real" value type, so boxing
does not have to occur. I had thought that was supposed to be a prime
benefit of using a the generic collections with value types. Am I wrong
here?

Or, when you say that I am now explicitly boxing vs implicitly boxing, are
you refering to the instatiation of the Element class? I'm still not sure
whether this is the way to go. It seems that if I am only going to read
from the list of elements once, then I'm losing by going with generics. But
what if I am going to load the collection once, and read from it many times?
Then it seems as though I am trading multiple unbox operations for casts.

I'm still not sure which is better/worse. Comments?


"Luc E. Mistiaen" <lu**********@advalvas.be.no.spam> wrote in message
news:uO**************@TK2MSFTNGP12.phx.gbl...

It seems to me that you just made the boxing explicit (and probably less
efficient than the implicit one).

/LM

"J.Marsch" <jm*****@newsgroup.nospam> wrote in message
news:ey**************@tk2msftngp13.phx.gbl...

All:

I have an interesting problem in front of me. does this sound
reasonable, or ridiculous?

I have to build something that is sort of like a style sheet for Windows
controls.
Picture a collection of dissimilar value types: a couple of Color types,
some ints, some strings etc.

I _could_ just use a hashtable of object to contain all of these, but
since they are value types, they would be boxed.

But what if I did this: (warning the syntax probably isn't spot on)
public class Element<T>
{
public T Value;
public Element(T value)
{
this.Value = value;
}
}

And then stored the element objects in my collection:
So, here is how I would store a couple of properties:
{
HashTable styleElements = new HashTable();
styleElements.Add("BackgroundColor", new Element<Color>(Color.Blue);
styleElements.Add("FontName", new Element<string>("Arial");
// and so on

//now accessing the collection:
aControl.BackgroundColor =
((Element<Color>)styleElements["BackgroundColor"]).Value;
}

Is this a horrible, horrible idea, or is it preferable to directly
storing the value types in the hashtable (thereby boxing them)?

[Luc E. Mistiaen]

I was refereing to the fact that you stash your value into a class member
which is equivalent to boxing.

/LM

"J.Marsch" <jm*****@newsgroup.nospam> wrote in message
news:um**************@TK2MSFTNGP12.phx.gbl...

Hmm. Looking back, I don't know whether I am much more efficient than
boxing, as I am now manually allocating a new class (the element), so
there is still an additional heap allocation.

But I want to get back to your comments about explicitly vs. implicitely
boxing. It was my understanding that if you pass a value type as the
parameter to a generic type, then you get a "real" value type, so boxing
does not have to occur. I had thought that was supposed to be a prime
benefit of using a the generic collections with value types. Am I wrong
here?

Or, when you say that I am now explicitly boxing vs implicitly boxing, are
you refering to the instatiation of the Element class? I'm still not sure
whether this is the way to go. It seems that if I am only going to read
from the list of elements once, then I'm losing by going with generics.
But what if I am going to load the collection once, and read from it many
times? Then it seems as though I am trading multiple unbox operations for
casts.

I'm still not sure which is better/worse. Comments?


"Luc E. Mistiaen" <lu**********@advalvas.be.no.spam> wrote in message
news:uO**************@TK2MSFTNGP12.phx.gbl...

It seems to me that you just made the boxing explicit (and probably less
efficient than the implicit one).

/LM

"J.Marsch" <jm*****@newsgroup.nospam> wrote in message
news:ey**************@tk2msftngp13.phx.gbl...

All:

I have an interesting problem in front of me. does this sound
reasonable, or ridiculous?

I have to build something that is sort of like a style sheet for Windows
controls.
Picture a collection of dissimilar value types: a couple of Color
types, some ints, some strings etc.

I _could_ just use a hashtable of object to contain all of these, but
since they are value types, they would be boxed.

But what if I did this: (warning the syntax probably isn't spot on)
public class Element<T>
{
public T Value;
public Element(T value)
{
this.Value = value;
}
}

And then stored the element objects in my collection:
So, here is how I would store a couple of properties:
{
HashTable styleElements = new HashTable();
styleElements.Add("BackgroundColor", new Element<Color>(Color.Blue);
styleElements.Add("FontName", new Element<string>("Arial");
// and so on

//now accessing the collection:
aControl.BackgroundColor =
((Element<Color>)styleElements["BackgroundColor"]).Value;
}

Is this a horrible, horrible idea, or is it preferable to directly
storing the value types in the hashtable (thereby boxing them)?

[Bruce Wood]

> Or, when you say that I am now explicitly boxing vs implicitly
boxing, are you refering to the instatiation of the Element class?

Yes. That's exactly what he's referring to. Creating an instance of
Element that holds your value type _is_ boxing. You're just doing what
the CLR would do anyway. This should illustrate two things to you:
first, that you should just shove the value types into the Hashtable
and let the CLR box them, and second, that for the most part those who
wring their hands shouting, "Boxing! Boxing! Oh the horror!" are for
the most part blowing smoke. Boxing is just simply what you've done in
the code you posted. It's not that big a deal... ceratinly not worth
building an entire new class and adding a bunch of machinery just to
avoid it.

Just let the CLR box the value type. You won't even notice. :)

To answer your other question, generics come into their own when you
want to create an aggregate structure (for example... there are other
situations besides aggregates) that will hold _one particular_ value
type. Then you can say: Hashtable<string, DateTime> and the DateTime
types stored in the hash table will _not_ be boxed. However, IMHO, this
is the least interesting part of generics: their run-time efficiency
benefits. The most interesting thing about generics is that they allow
for much better compile-time checking of your code, since the compiler
now understands what it is you want to do. As a result, you get
type-safe collections, which to me is far more significant than saving
a few cycles here and there (although the latter is nice, too).

In your case, generics won't help you: your collection does not hold a
uniform type of thing. This is one case in which the current
(non-generic) collections are what you need. As I said, just ignore the
whole boxing thing... it's not going to have a significant impact.

[J.Marsch]

That clears things up, I believe. Thank you both for posting, I appreciate
it!
"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Or, when you say that I am now explicitly boxing vs implicitly

boxing, are you refering to the instatiation of the Element class?

Yes. That's exactly what he's referring to. Creating an instance of
Element that holds your value type _is_ boxing. You're just doing what
the CLR would do anyway. This should illustrate two things to you:
first, that you should just shove the value types into the Hashtable
and let the CLR box them, and second, that for the most part those who
wring their hands shouting, "Boxing! Boxing! Oh the horror!" are for
the most part blowing smoke. Boxing is just simply what you've done in
the code you posted. It's not that big a deal... ceratinly not worth
building an entire new class and adding a bunch of machinery just to
avoid it.

Just let the CLR box the value type. You won't even notice. :)

To answer your other question, generics come into their own when you
want to create an aggregate structure (for example... there are other
situations besides aggregates) that will hold _one particular_ value
type. Then you can say: Hashtable<string, DateTime> and the DateTime
types stored in the hash table will _not_ be boxed. However, IMHO, this
is the least interesting part of generics: their run-time efficiency
benefits. The most interesting thing about generics is that they allow
for much better compile-time checking of your code, since the compiler
now understands what it is you want to do. As a result, you get
type-safe collections, which to me is far more significant than saving
a few cycles here and there (although the latter is nice, too).

In your case, generics won't help you: your collection does not hold a
uniform type of thing. This is one case in which the current
(non-generic) collections are what you need. As I said, just ignore the
whole boxing thing... it's not going to have a significant impact.