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

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

Show quoteHide quote

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

hufaun***@yahoo.com wrote:
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.

Unique Identifier for a computer.
BitConverter.ToInt32 - weird optimization?
XmlSerializer without namespaces?
.NEt 2.0 : Threading questions
Wanting to read XML blob from configuration