> A problem (big problem) with serialization is that it often leads to > fragile interfaces. One might want to have precise control over > the serialization so a change in the implementation doesn't affect > compatibility. Serializing AnyObjectId should not depend on the > implementation de jour. Second, how do we handle subclasses? > > But maybe leaving it this way would be our way of saying that > the interface may break at any time, promise. > Well, we can of course implement writeObject / readObject (or do so if/when compatibility breaks, and it's cared about) That's how I tend to view it anyway (may break at any time) - you can't just update a jar library to a significantly new version and expect it all to stay compatible. Also for half my use, it's not for persistence, it's for transferring over the wire to a slave process. Thinking a bit more clearly, I probably don't need AnyObjectId, just ObjectId - but I've also missed RefSpec and URIish as they're used in RemoteConfig.. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
