ISerializable interface

[cristianbuse]

Interface ISerializable:

Option Explicit
'@Interface

Public Function GetData() As Dictionary
    Err.Raise 5, , "This is an interface and should not be called directly"
End Function

In advance of the serializer, should this library allow objects that are not Collection or Dictionary?

This would require the above interface and basically each such object is responsible to Implement ISerializable and to return a Dictionary instance via the Private ISerializable_GetData() As Dictionary implemented method. The upcoming Serializer method would then serialize the returned Dictionary.

The benefits are obvious, however this will add the extra class to all users codebases, even if not used.

Thanks!

[sancarn]

FWIW I've wondered about exactly the same thing with stdVBA. My conclusion was that the dependency wasn't worth it, and an IDispatch based standard made more sense for serialisables.

For instance if I wanted to use this library and stdVBA I'd then need to implement said interface on all stdVBA classes I wanted to serialise... I'm really torn on this. I think more generally a IDispatch#toSerialisable method on each class/object makes more sense. As that can be used by many different libraries without needing a single defined interface.

It should also be noted that interfaces are not compatible between projects.(In the sense that Dim x as someInterface: set x = getExternal() only works if both projects are referring to the same interface class...

[cristianbuse]

Thanks @sancarn ! These are really good points.

[sancarn]

This meme comes to mind

[cristianbuse]

😆 Didn't know about this one. Spot on - one interface module to rule them all.