Immutable Hashtable....

[Johnny Cash]

Can anyone tell me how to make a Hashtable immutable? I see that
Hashtable has the "IsReadOnly" property, but I can't see how I am
supposed to actually make it immutable.

Thanks!
BCOT.

[Arne Janning]

"Johnny Cash" schrieb

Can anyone tell me how to make a Hashtable immutable? I see that
Hashtable has the "IsReadOnly" property, but I can't see how I am
supposed to actually make it immutable.

Hi Johnny,

HashTable.IsReadOnly will always be false by default.

If you want an "immutable" HashTable then darive a new Class from HashTable
and override the IsReadOnly-Property.

Look at the foolowing code:

using System;
using System.Collections;
public class ReadOnlyHashTable : Hashtable
{
private bool _IsReadOnly = true;
public ReadOnlyHashTable()
{
}

public ReadOnlyHashTable(bool IsReadOnly)
{
_IsReadOnly = IsReadOnly;
}

internal void SetReadOnly(bool readOnly)
{
_IsReadOnly = readOnly;
}

public override bool IsReadOnly
{
get
{
return _IsReadOnly;
}
}

public override void Add(object key, object value)
{
if (_IsReadOnly)
{
throw new Exception("ReadOnly!");
}
base.Add (key, value);
}

public override object this[object key]
{
get
{
return base[key];
}
set
{
if (_IsReadOnly)
{
throw new Exception("ReadOnly!");
}
base[key] = value;
}
}
}

Cheers

Arne Janning

[Jeff Louie]

Arne... This code looks a bit suspect to me as it uses inheritance, not
containment. This is what the docs say:

==== snip =====
A collection that is read-only does not allow the addition, removal, or
modification of elements after the collection is created.

A collection that is read-only is simply a collection with a WRAPPER
that
prevents modifying the collection; therefore, if changes are made to the
underlying collection, the read-only collection reflects those changes.
=====/snip=======

http://www.parashift.com/c++-faq-lit...heritance.html

[21.1] Should I hide member functions that were public in my base class?

Never, never, never do this. Never. Never!

Attempting to hide (eliminate, revoke, privatize) inherited public
member
functions is an all-too-common design error. It usually stems from muddy
thinking.

More at:

http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

Regards,
Jeff

If you want an "immutable" HashTable then darive a new Class from

HashTable
and override the IsReadOnly-Property.

public override void Add(object key, object value)
{
if (_IsReadOnly)
{
throw new Exception("ReadOnly!");
}
base.Add (key, value);
}

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Arne Janning]

Hi Jeff!

"Jeff Louie" schrieb

Arne... This code looks a bit suspect to me as it uses inheritance, not
containment. This is what the docs say:

==== snip =====
A collection that is read-only does not allow the addition, removal, or
modification of elements after the collection is created.

A collection that is read-only is simply a collection with a WRAPPER
that
prevents modifying the collection; therefore, if changes are made to the
underlying collection, the read-only collection reflects those changes.
=====/snip=======

http://www.parashift.com/c++-faq-lit...heritance.html
I don't see what this has to do with my code...
[21.1] Should I hide member functions that were public in my base class?

Never, never, never do this. Never. Never!

Attempting to hide (eliminate, revoke, privatize) inherited public
member
functions is an all-too-common design error. It usually stems from muddy
thinking.

More at:

http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

I didn't hide or eliminate a public member. Actually this isn't possible in
C#.

What is your problem?

Cheers

Arne Janning

[Jeff Louie]

Arne...Well 1) Your solution uses inheritance to convert a read/write
interface
to read only. I argue that this should be done with containment.

http://www.geocities.com/jeff_louie/OOP/oop7.htm

The MS docs argue that this should be done with containment.
"A collection that is read-only is simply a collection with a WRAPPER
that prevents modifying the collection."

2) Throwing an exception instead of providing an implementation violates
the
Liskov Substitution Principle--> The subclass may add behaviors to the
base
class, but the behaviors of the base class must still hold true for the
subclass.
In real world terms, the user of the class expects to be able to add an
element
and does not expect the add method to throw an exception. The contract
is
broken at runtime. Wrapping the collection is a wrapper class and
providing
only setters, results in compile time enforcement of the read only
contract.

I didn't hide or eliminate a public member. Actually this isn't possible in
C#.<

3) "Attempting to hide (eliminate, revoke, privatize) inherited public
member
functions is an all-too-common design error. It usually stems from muddy
thinking." By throwing an exception you revoked the contract.
What is your problem?<

Nice touch.

Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!