[Mono-dev] Serialization strategies for compatibility.

[Jonathan Pryor]

On Mon, 2006-06-05 at 00:42 -0400, Miguel de Icaza wrote:
>     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> Some classes now implemented some new interfaces that were not present
> in .NET 1.1.   My question is: what is the justification to add new
> implemented interfaces to classes,

No idea.

>  and could we get away by just
> sprinkling "ISerializable" on our classes, or would that be considered a
> massive breach of API compatibility?    

It's only a breach of API compatibility if people find out about it. :-)

That is, if people know the class implements a given interface, they may
rely on that fact, which would hinder portability to .NET.

Further, there are three ways people would find out what interfaces a
type implements:

  - Documentation
  - Reflection
  - Reading Mono's Sources

Since Documentation follows .NET's types, no one would determine the new
interfaces only by reading the documentation, which leaves Reflection &
Mono's sources.

Microsoft has frequently said to treat Reflection with a grain of salt
(newly added members may cause exceptions to be generated in the future
due to newly created ambiguities, etc.), so it could be ignored.

And anyone reading the sources gets whatever they deserve. :-)

So just sprinkling ISerializable everywhere may be acceptable, as long
as it's not documented.

Alternatively, if Reflection is an important scenario, we'd need a way
to "hide" the interface from being returned by Reflection, which could
be done via an internal attribute:

	[HideFromReflection (typeof(ISerializable))]
	class Color : ISerializable { /* ... */ }

though this path may lead to madness as well.

Another shot against caring about Reflection is that Reflection will
return internal interfaces & attributes, so your approach of defining
additional internal attributes would still result in them being returned
by Reflection, thus (in principal) breaking "absolute compatibility
with .NET" (as types would be presented which aren't under .NET).

End result: I'd suggest just sprinkling ISerializable where needed and
_not_ documenting it.  It's an implementation detail, and not
significantly worse than the alternatives.

 - Jon