Develop Reference

Is there an easy way to have a dictionary-like object that cannot be added to, but whose values can be modified?

Suppose I have a class Composite that is constructed from a dictionary of instruments and weights.
public IReadOnlyDictionary<Instrument, double> Underlyings{ get; private set; }
public Composite(
Id id,
Currency currency,
Dictionary<Instrument, double> underlyings
)
{
Underlyings= underlyings;
}
}
This class is exposed to the client, and I want the client to be able to modify the existing keys' values within Underlyings, but not add new key-value pairs to Underlyings.
Then making Underlyings a ReadOnlyDictionary will not work as the client code will not be able to modify the values for existing keys. So my solution was to take the wrapper around a dictionary from this answer and modify the setter for TValue IDictionary<TKey, TValue>.this[TKey key] such that existing values can be modified. But this seems like a silly solution - is there an easier way than writing a wrapper class to have a dictionary which has modifiable existing key-value pairs, but cannot have new key-value pairs added to it? Apologies for the very simplistic question.

No, there is no standard dictionary that only allows updates. Its all or nothing.
As you have discovered, you have to create it your own, or find an implementation that is already there. Overriding the Add and this[] property is a solution that might work for you.

You can use ReadOnlyDictionary, but provide another method to modify value of given key. Something like:
Dictionary<KeyType, ValueType> _dictionary;
public ReadOnlyDictionary<KeyType, ValueType> Dictionary => new ReadOnlyDictionary<KeyType, ValueType>(_dictionary);
public void ChangeValue(KeyType key, ValueType value) => _dictionary[key].Value = value;

As you said, create a wrapper over a dictionary or inherit from the dictionary class an override Add.

Not a good way but a hack.
Generate a wrapper around your data and Use a ReadOnlyDictionary which is introduced in .NET 4.5.
class MyDataWrapper<T>
{
public T Data { set; get; }
}
var dicData = new Dictionary<int, MyDataWrapper<string>>();
dicData[0] = new MyDataWrapper<string> { Data = "0" };
dicData[1] = new MyDataWrapper<string> { Data = "0" };
var myDic = new ReadOnlyDictionary<int, MyDataWrapper<string>>(dic);
myDic[1].Data = "2";
// myDic[1] = new ... compile error
// myDic.Add() compile error

How to Ensure Immutability of a Generic

This example is in C# but the question really applies to any OO language. I'd like to create a generic, immutable class which implements IReadOnlyList. Additionally, this class should have an underlying generic IList which is unable to be modified. Initially, the class was written as follows:
public class Datum<T> : IReadOnlyList<T>
{
private IList<T> objects;
public int Count
{
get;
private set;
}
public T this[int i]
{
get
{
return objects[i];
}
private set
{
this.objects[i] = value;
}
}
public Datum(IList<T> obj)
{
this.objects = obj;
this.Count = obj.Count;
}
IEnumerator IEnumerable.GetEnumerator()
{
return this.GetEnumerator();
}
public IEnumerator<T> GetEnumerator()
{
return this.objects.GetEnumerator();
}
}
However, this isn't immutable. As you can likely tell, changing the initial IList 'obj' changes Datum's 'objects'.
static void Main(string[] args)
{
List<object> list = new List<object>();
list.Add("one");
Datum<object> datum = new Datum<object>(list);
list[0] = "two";
Console.WriteLine(datum[0]);
}
This writes "two" to the console. As the point of Datum is immutability, that's not okay. In order to resolve this, I've rewritten the constructor of Datum:
public Datum(IList<T> obj)
{
this.objects = new List<T>();
foreach(T t in obj)
{
this.objects.Add(t);
}
this.Count = obj.Count;
}
Given the same test as before, "one" appears on the console. Great. But, what if Datum contains a collection of non-immutable collection and one of the non-immutable collections is modified?
static void Main(string[] args)
{
List<object> list = new List<object>();
List<List<object>> containingList = new List<List<object>>();
list.Add("one");
containingList.Add(list);
Datum<List<object>> d = new Datum<List<object>>(containingList);
list[0] = "two";
Console.WriteLine(d[0][0]);
}
And, as expected, "two" is printed out on the console. So, my question is, how do I make this class truly immutable?

You can't. Or rather, you don't want to, because the ways of doing it are so bad. Here are a few:
1. struct-only
Add where T : struct to your Datum<T> class. structs are usually immutable, but if it contains mutable class instances, it can still be modified (thanks Servy). The major downside is that all classes are out, even immutable ones like string and any immutable class you make.
var e = new ExtraEvilStruct();
e.Mutable = new Mutable { MyVal = 1 };
Datum<ExtraEvilStruct> datum = new Datum<ExtraEvilStruct>(new[] { e });
e.Mutable.MyVal = 2;
Console.WriteLine(datum[0].Mutable.MyVal); // 2
2. Create an interface
Create a marker interface and implement it on any immutable types you create. The major downside is that all built-in types are out. And you don't really know if classes implementing this are truly immutable.
public interface IImmutable
{
// this space intentionally left blank, except for this comment
}
public class Datum<T> : IReadOnlyList<T> where T : IImmutable
3. Serialize!
If you serialize and deserialize the objects that you are passed (e.g. with Json.NET), you can create completely-separate copies of them. Upside: works with many built-in and custom types you might want to put here. Downside: requires extra time and memory to create the read-only list, and requires that your objects are serializable without losing anything important. Expect any links to objects outside of your list to be destroyed.
public Datum(IList<T> obj)
{
this.objects =
JsonConvert.DeserializeObject<IList<T>>(JsonConvert.SerializeObject(obj));
this.Count = obj.Count;
}
I would suggest that you simply document Datum<T> to say that the class should only be used to store immutable types. This sort of unenforced implicit requirement exists in other types (e.g. Dictionary expects that TKey implements GetHashCode and Equals in the expected way, including immutability), because it's too difficult for it to not be that way.

Kind of hacky, and definitely more confusing than it's worth in my opinion, but if your T is guaranteed to be serializable, you can store string representations of the objects in your collection rather than storing the objects themselves. Then even if someone pulls an item from your collection and modifies it, your collection would still be intact.
It would be slow and you'd get a different object every time you pulled it from the list. So I'm not recommending this.
Something like:
public class Datum<T> : IReadOnlyList<T>
{
private IList<string> objects;
public T this[int i] {
get { return JsonConvert.DeserializeObject<T>(objects[i]); }
private set { this.objects[i] = JsonConvert.SerializeObject(value); }
}
public Datum(IList<T> obj) {
this.objects = new List<string>();
foreach (T t in obj) {
this.objects.Add(JsonConvert.SerializeObject(t));
}
this.Count = obj.Count;
}
public IEnumerator<T> GetEnumerator() {
return this.objects.Select(JsonConvert.DeserializeObject<T>).GetEnumerator();
}
}

It's impossible. There's no possible way to constrain the generic type to be immutable. The best that you can possibly do is write a collection that cannot allow the structure of that collection to be modified. There is no way to prevent the collection from being used as a collection of some mutable type.

think that such collections are not match OOP, because this design leads to specific co-relation between independent classes - collection and it's items. How one class can change behavior of other without knowlege of each other?
So suggestions of serialization and so can allow you to do it on hacky way, but better is to decide if it's so required to make collection of immutable items, who trys to change them except your own code? May be better "to not mutate" items rather than try "make them immutable".

I faced the same problem, where I implement an object (say CachedData<T>) which handles a cached copy of the property of another object (say T SourceData). When calling the constructor of CachedData, you pass a delegate which returns a SourceData. When calling CachedData<T>.value, you get a copy of SourceData, which is updated every now and then.
It would make no sense to try caching an object, as .Value would only cache the reference to the data, not the data itself. It would only make sense to cache data types, strings, and perhaps structures.
So I ended up:
Thoroughly documenting CachedData<T>, and
Throwing an error in the constructor if T is neither a ValueType, a Structure, or a String. Some like (forgive my VB): If GetType(T) <> GetType(String) AndAlso GetType(T).IsClass Then Throw New ArgumentException("Explain")

Protobuf-net : Nested IEnumerable objects

I am using Protobuf-net to serialize a custom nested list. I understand that native lists cannot be nested directly, which is why I have used a container object for the inner list. However, I would also like to make my container objects IEnumerable but this means Protobuf-net throws it out with the error:
Nested or jagged lists and arrays are not supported
Here is an example of my list structure which causes the error:
[ProtoContract]
public class MyOuterList<T>
{
[ProtoMember(1)]
readonly List<MyInnerList<T>> nestedData = new List<ObjectList<T>>();
}
[ProtoContract]
public class MyInnerList<T> : IEnumerable<T>
{
[ProtoMember(1)]
private readonly List<T> data = new List<T>();
}
The fix is to remove IEnumerable from MyInnerList but obviously that prevents it being directly iterable. Is there a sneaky attribute like [ProtobufCustomObjectSoPleaseIgnoreIEnumerable] that could be used?
The best alternative I have come up with so far is to use an Enumerable property as shown below but I fear that the property could still be cast back to a list again. I would prefer to be using GetEnumerator/yield in some way but I can't see how.
[ProtoContract]
public class MyInnerList<T>
{
[ProtoMember(1)]
private readonly List<T> data = new List<T>();
public IEnumerable<T> Data
{
get { return this.data; }
}
}

Is there a sneaky attribute like [ProtobufCustomObjectSoPleaseIgnoreIEnumerable] that could be used?
yup:
[ProtoContract(IgnoreListHandling=true)]
public class MyInnerList<T> : IEnumerable<T>
{
[ProtoMember(1)]
private readonly List<T> data = new List<T>();
}
sneaky is sneaky. IgnoreListHandling has the intellisense documentation:
If specified, do NOT treat this type as a list, even if it looks like one.
Also, due to multiple requests like this one, I plan on looking at implementing support for jagged arrays / lists shortly. The plan is to basically get the runtime to spoof the wrapper with a member (field 1) in the serializer's imagination, so you can use List<List<T>> and it'll work just like your model above (it will even be wire-compatible, since you sensibly chose field 1).

Make object that encapsulates List<> accessable via [] operator?

I have a class that I made that is basically an encapsulated List<> for a certain type. I can access the List items by using [] like if it was an array, but I don't know how to make my new class inherit that ability from List<>. I tried searching for this but I'm pretty sure I don't know how to word correctly what I want to do and found nothing useful.
Thanks!

That's called an indexer:
public SomeType this[int index] {
get { }
set { }
}

List already have a definition for the Indexer so there is no need to change that code. It will work by default.
public class MyClass : List<int>
{
}
And we can access the indexer here. Even though we havent implemented anything
MyClass myclass = new MyClass();
myclass.Add(1);
int i = myclass[0]; //Fetching the first value in our list ( 1 )
Note that the List class isn't designed to be inherited. You should be encapsulating it, not extending it. – Servy
And this would look something like
public class MyClass
{
private List<int> _InternalList = new List<int>();
public int this[int i]
{
get { return _InternalList[i]; }
set { _InternalList[i] = value; }
}
}

That's called an indexer.
Indexers allow instances of a class or struct to be indexed just like
arrays. Indexers resemble properties except that their accessors take
parameters.
Indexers enable objects to be indexed in a similar manner to arrays.
A get accessor returns a value. A set accessor assigns a value.
The this keyword is used to define the indexers.
The value keyword is used to define the value being assigned by the set indexer.
Here is an EXAMPLE.

XmlSerializer error Serializing Interface Objects

I have a list of objects that implement a common interface. If I try to simply serialize it I get a nice exception that tells me that the serializer cannot serialize interfaces:
private readonly ObservableCollection<ICanHasInterface> children = new ObservableCollection<ICanHasInterface>();
public ObservableCollection<ICanHasInterface> Children
{
get { return children; }
}
=> "Cannot serialize member ... of type ... because it is an interface"
Apparently asking the serializer to get the type of the objects and mark the XmlElement with the attribute xsi:type (which is done if an object inherits from another class) is too much.
So because I do not want to implement IXmlSerializable, I thought up a workaround which looked promising initially:
private readonly ObservableCollection<ICanHasInterface> children = new ObservableCollection<ICanHasInterface>();
[XmlIgnore()]
public ObservableCollection<ICanHasInterface> Children
{
get { return children; }
}
[XmlElement("Child")]
public List<object> ChildrenSerialized
{
get
{
return new List<object>(Children);
}
set
{
Children.Clear();
foreach (var child in value)
{
if (child is ICanHasInterface) AddChild(child as ICanHasInterface);
}
}
}
With this at least the serialisation works just fine (Note: Either specify XmlInclude attributes for the types that can be in the original list or hand over an array of types in the constructor of the serializer), however if the object is deserialized the Children collection ends up empty because the set block is never reached during deserialization, I am quite clueless as to why this is; any ideas?

On deserialization the serializer uses your property getter to get the collection instance and then calls Add() on it for each item. It does not call your property setter. Something like this:
YourClass c = new YourClass();
c.ChildrenSerialized.Add(ReadValue());
...
In order to keep the collections synchronized you'd need to customize the Add() behavior of the collection you return from the property getter.
A better option is to change the ChildrenSerialized property to use an object[]. For arrays, the serializer reads the value into an array and then calls your property setter with the value.