On 05/04/2011 02:37 PM, Stéphane Ducasse wrote:
something that would be good is to have SActiveRecord as a trait like in SqueakSave this way no need to change the superclass definition of your domain to save your objects.
As far as I'm aware, traits don't do instance variables, of which active record has a few, as well as a class instance variable and a class variable. It also actually uses the class hierarchy throughout to allow classes to do queries on all its instances and sub instances. SDActiveRecord is a bundle of both behavior and state; not suitable for a trait.
Beyond that, it's an opinionated library, your superclass should be SDActiveRecord, because you shouldn't be trying to use an object that has some other superclass as the aggregate root of a persistent bundle of objects. All of your business objects don't need to subclass SDActiveRecord, just the aggregate roots. Member biz objects can use whatever superclass they like as long as it's serializable.
-- Ramon Leon http://onsmalltalk.com
