Indexed Properties

I wonder about the pros and cons of a setter for an index property. As
an example let's look at the Dataset

DataSet ds;
....
ds.Tables[0] = new Table(); //Assume Tables[0] exists already

The above will generate a compile error. Why is this allowed? Tables
basically looks like an array/list to the user and arrays and lists
allow this assignment. What is the logic behind this limitation? What
are the pros/cons in general, i.e. not just for the above example but
any custom class that has an indexed property?

Thanks

pbromberg
Tue Feb 13 12:55:02 CST 2007

I'm not exactly sure what this issue is here, but the correct object is not
"Table", its new "DataTable()". The preferred construct would be
ds.Tables.Add(yourDataTable);

Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net




"hufaunder@yahoo.com" wrote:

> I wonder about the pros and cons of a setter for an index property. As
> an example let's look at the Dataset
>
> DataSet ds;
> .....
> ds.Tables[0] = new Table(); //Assume Tables[0] exists already
>
> The above will generate a compile error. Why is this allowed? Tables
> basically looks like an array/list to the user and arrays and lists
> allow this assignment. What is the logic behind this limitation? What
> are the pros/cons in general, i.e. not just for the above example but
> any custom class that has an indexed property?
>
> Thanks
>
>

hufaunder
Tue Feb 13 13:30:36 CST 2007

Your right, that should have read

ds.Tables[0] = new DataTable().

I know you can add a table with ds.Tables.Add. But if I want to
replace(!) a table I'll have to remove it first and then add the new
one rather then just replace it like in the statement above. So what
is the logic behind this limitation?

Again, note that I just take the DataSet as an example. The reason I
am asking is because I wonder about what should be offered in a custom
class.

Thanks

Tom
Tue Feb 13 14:59:44 CST 2007

hufaunder@yahoo.com wrote:
> Your right, that should have read
>
> ds.Tables[0] = new DataTable().
>
> I know you can add a table with ds.Tables.Add. But if I want to
> replace(!) a table I'll have to remove it first and then add the new
> one rather then just replace it like in the statement above. So what
> is the logic behind this limitation?
>
> Again, note that I just take the DataSet as an example. The reason I
> am asking is because I wonder about what should be offered in a custom
> class.

I think part of the reason the DataTableCollection indexer is read-only is
that it isn't always safe to remove a table from the collection. The proper
way to remove a table would be to call CanRemove first and then Remove.
This is due to the relational nature of tables in a dataset. I would think
that if the table at [0] can't be removed then it could lead to confusion as
to why the assigment of ds.Tables[0] = new DataTables() failed.

In your custom class, if it is always safe to remove items then I see no
reason to make the indexer read-only.
--
Tom Porterfield