[Mono-dev] Serialization strategies for compatibility.

[Mike Welham]

> >     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.
>

Big fixes is one possible reason. (IIRC System.Threading.WaitHandle
neglected to implement IDisposable initially. It does in 2.0 and now
maybe in 1.1 SP-N.)

> >  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.
>

...

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

In general I agree, but ISerializable is a bit of a special case due
to remoting. It is unlkiely but conceivable that somewhere in remoting
plumbing (in Mono or another tool) somebody might "if(x is
ISerializable)...".

It might be worth considering an IMonoSerializable interface?

Mike