Hello, > The compatibility of the inner representation of the Mono and .NET > classes is very important, and, in some cases, we need to break API > compatibility to achieve it. If a class is not implement ISerializable > interface and it has different from .NET inner structure, we have a > problem with interoperability, specially in remoting, where the server > and the client can run on different machines with different runtimes. > This problem raises not only in the System.Collection.Specialized > namespace, and we should make a global decision about an our behavior in > this case.
Am not sure that "to keep compatibility we must break compatibility" is a good argument. If this is so important, then we might have to revisit the problematic classes implementation and try to make it so it works with the field names that the framework expects. But adding a public ISerializable sounds like a bad idea, currently am thinking of code that the compiler would compile on Mono, but would not on Windows, producing incompatible binaries. > This solution requires changes in the Mono's runtime. > Another possibility is to change implementation of the class to be fully > compatible with implementation in .NET. In the HybridDictionary class, > for example, we should return the previous version of the class and > treat Hashtable and List as two separate fields. Another alternative is > to break the API compatibility and implement the ISerializable interface > to manage the serialization info, as I made. > What strategy is appropriate? Any other ideas? Reimplementing the class to match the exposed internals would be the best path in my opinion. Miguel _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list