We have long now been able to let the computer handle memory management in our programs via garbage collection. Why not let it also handle persistence and change management? I think these are things that should be built-in and it would be handled more easily by the virtual machine. There could be a low level API for hooking up different persistence strategies (relational, object, etc) and code would no longer have to be dirtied up with SQL or even worse HSQL. At the very least, change management of objects should be handled by the VM. How much easier would exception handling be if you could also rollback all the changes that had occurred and you could get back to the state you were in before the error? I think these should be the new primitives.
Gemstone is the realization of this on the server. It would be nice to make the code on the client as transparent as well. I know some might laugh at this idea, but I think it has merit. Just like garbage collection seemed strange at first, why not allow automatic persistent management as well?
Subscribe to:
Post Comments (Atom)
Posts
1 comment:
I think garbage collection is a function most people can agree upon. Simply stated, it simply collects the memory for those objects that are no longer referred to by other objects. When it comes to persistency, transaction handling and change management there are so many different patterns to use, that implementing this behaviour in the VM does not make sense.
Persistency handling is best expressed as frameworks (TOPLink, Glorp, GemStone/S) written in Smalltalk. Sure those frameworks need support in the VM, but the more code we can have in Smalltalk, the easier it will be to adopt the functionality to the various needs projects have. The strategy needed will differ a lot between the various frameworks, and it changes as new lessons are learned. Representing this behaviour in the VM is too inflexible.
Change management is probably something that is good to have at the VM level, as a Smalltalk implementation would perform slowly, and clutter the code too much. In fact such support is in the VM: http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&entry=3272493815 Again, I think only the basics should be at the VM level. Rollback for example, should be at the Smalltalk framework level. In fact some persistency frameworks will do a copy of objects before write, and then rollback is not used at all.
Post a Comment