Q: syntax for Hashtable within a Hashtable?

[Matt C.]

I bet I know the answer already.

I have a hashtable (hMaster) that holds several hashtables ("hTables") each
of which holds other hashtables ("hColumns"). Presently, I am getting at
the info I want thusly (this compiles, at least):

Hashtable hTable = (Hashtable)hMaster[tableName];
Hashtable hColumn = (Hashtable)hTable[columnName];
return hColumn.ContainsKey(codeValue);

This is kind of cumbersome. I'd rather use something like this:

return hMaster[tableName].[columnName].ContainsKey(codeValue);

But this syntax is not supported. I'm not surprised by this, I was asking a
lot, but maybe there is a cleaner approach than what I'm actually using with
all the steps and casts?

Matt

(P.S. I realize I could have leveraged ADO.NET dataset stuff to check my
code values. But I'm not up to speed on all the fancy DataSet/DataTable
stuff, so I stuck with what made sense to me. Also I had the idea that keys
from Hashtables would be faster, there's going to be a lot of these
validations.)

[Patrick Altman]

Why not:

<snip>
return
((Hashtable)((Hashtable)hMaster[tableName]).[columnName]).ContainsKey(codeVa
lue);
</snip>

Still a bit cumbersome so it might not be what you were looking for.

Another solution would be to create a object that inherits from Hashtable
and override the indexer so that it can only contain Hashtable objects and
therefore will be strongly typed and won't require the type casting.

Patrick Altman

"Matt C." <ca*****@my-deja.com> wrote in message
news:Xn******************************@207.46.248.1 6...

I bet I know the answer already.

I have a hashtable (hMaster) that holds several hashtables ("hTables") each of which holds other hashtables ("hColumns"). Presently, I am getting at
the info I want thusly (this compiles, at least):

Hashtable hTable = (Hashtable)hMaster[tableName];
Hashtable hColumn = (Hashtable)hTable[columnName];
return hColumn.ContainsKey(codeValue);

This is kind of cumbersome. I'd rather use something like this:

return hMaster[tableName].[columnName].ContainsKey(codeValue);

But this syntax is not supported. I'm not surprised by this, I was asking a lot, but maybe there is a cleaner approach than what I'm actually using with all the steps and casts?

Matt

(P.S. I realize I could have leveraged ADO.NET dataset stuff to check my
code values. But I'm not up to speed on all the fancy DataSet/DataTable
stuff, so I stuck with what made sense to me. Also I had the idea that keys from Hashtables would be faster, there's going to be a lot of these
validations.)

[Nicholas Paldino [.NET/C# MVP]]

Matt,

As suggested, you will have to use a cast. However, in .NET 2.0, with
Generics, you will be able to use the Generic Dictionary class, which will
be strongly typed, therefore eliminating the need for the cast.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Matt C." <ca*****@my-deja.com> wrote in message
news:Xn******************************@207.46.248.1 6...

I bet I know the answer already.

I have a hashtable (hMaster) that holds several hashtables ("hTables")
each
of which holds other hashtables ("hColumns"). Presently, I am getting at
the info I want thusly (this compiles, at least):

Hashtable hTable = (Hashtable)hMaster[tableName];
Hashtable hColumn = (Hashtable)hTable[columnName];
return hColumn.ContainsKey(codeValue);

This is kind of cumbersome. I'd rather use something like this:

return hMaster[tableName].[columnName].ContainsKey(codeValue);

But this syntax is not supported. I'm not surprised by this, I was asking
a
lot, but maybe there is a cleaner approach than what I'm actually using
with
all the steps and casts?

Matt

(P.S. I realize I could have leveraged ADO.NET dataset stuff to check my
code values. But I'm not up to speed on all the fancy DataSet/DataTable
stuff, so I stuck with what made sense to me. Also I had the idea that
keys
from Hashtables would be faster, there's going to be a lot of these
validations.)

[Jon Skeet [C# MVP]]

Matt C. <ca*****@my-deja.com> wrote:

I bet I know the answer already.

I have a hashtable (hMaster) that holds several hashtables ("hTables") each
of which holds other hashtables ("hColumns"). Presently, I am getting at
the info I want thusly (this compiles, at least):

Hashtable hTable = (Hashtable)hMaster[tableName];
Hashtable hColumn = (Hashtable)hTable[columnName];
return hColumn.ContainsKey(codeValue);

This is kind of cumbersome. I'd rather use something like this:

return hMaster[tableName].[columnName].ContainsKey(codeValue);

But this syntax is not supported. I'm not surprised by this, I was asking a
lot, but maybe there is a cleaner approach than what I'm actually using with
all the steps and casts?

Why are you surprised by this? hMaster[tableName] is of type Object,
not Hashtable. There's nothing to stop you putting something completely
different in hMaster.

Generics in 2.0 will help you here, as you'll be able to tell the
compiler that hTable is a Dictionary<string,Dictionary<string,object>>
or whatever.

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

[Matt C.]

"Patrick Altman" <paltmanATgmailDOTcom> wrote in
news:#X**************@TK2MSFTNGP11.phx.gbl:

Why not:

<snip>
return
((Hashtable)((Hashtable)hMaster[tableName]).[columnName]).ContainsKey(co
deVa lue);
</snip>

Still a bit cumbersome so it might not be what you were looking for.

Sweet. Thanks.

(You actually have to remove the dot between tableName and columnName, for
anyone else making use of this. My fault, I started us down that road.)

That is unlovely to read, but it does get rid of the temp variables which is
what I was really after.

I'm assuming the inline casting is actually going to be a little faster than
creating the temp Hashtable and assigning the internal Hashtables one step
at a time. But I'm not sure of that; maybe they amount to the same thing
once compiled. Does anyone know offhand if the nested parenthetical casting
above is faster than using temp variables in separate steps?

Matt

P.S. Thanks to those who pointed out generics in .NET 2.0. I'm looking
forward to those, this is only about the 100th time they would have come in
handy.