Hi Marco, Though I'm happy to do baseline maintenance and merging of patches for the project, I don't have a lot of time to invest in it. And sweeping changes would need extremely careful review, and would no doubt cause further issues for other people. So I have to say no, in my distribution, we're down to minimal, super-conservative maintenance. Feel free to start a fork.
Best, Marijn On Thu, Jan 30, 2014 at 12:33 AM, Marco Baringer <m...@bese.it> wrote: > > i'd like to replace build-dao-methods with a set of slots on the > dao-class instance, a common root in the class hierarchy (which would be > dao-object) and a set of methods specialized on dao-object. before i do > the work i want to make sure the patch won't be rejected on principle. > > my main problem with build-dao-methods is that it generates a new, > distinct, method on the generic functions for every dao-class instance. > when you have a lot of dao-class instances it becomes difficult to > figure out which methods are auto generated and which are 'real' and may > do something different than the standard methods (and implementing these > non standard methods requires rewriting a lot of the code in > build-dao-methods since call-next-method doesn't actually do > anything). > > another problem, though i haven't actually had this problem in practice, > is that build-dao-methods defines shared-initialize :after method on the > given class to call fetch-defaults; this makes it impossible for me to > define my own shared-initialize :after method to perform whatever extra > initialization i may have. i can imagine a work around to this issue by > defining the dao-class and then subclassing it to get the actual > functionality i need, or call fetch-defaults myself, but being able to > just define an :after method and have things Just Work(TM) seems > simpler. > > there are a few things the build-dao-methods does that, i think, i can > maintain using just the plain old mop: > > 1. only defining update-dao and upsert-dao when the class has value > fields. by inspecting the class at compute-class-precedence-list time > we can inject either dao-value-object or dao-key-only-object and then > define the update/upsert-dao methods on dao-value-object and not > dao-key-only-object. > > fwiw i think these methods should be defined for all dao objects; > just because all the slots of the object are its primary key doesn't > mean that changing one of those slots doesn't make sense (this can > happen in practice when working with relation tables whose columns > are all foreign keys and to preserve uniqueness of the relation the > primary key consists of all (usually 2) columns). > > 2. the methods defined by build-dao-methods close over a set of > precomputed values (column names and sql templates). by storing these > values in the class instance directly we still avoid recomputing them > every time the method is called and gain the ability to, easily, > inspect their values at run time for debugging purposes. > > the one thing build-dao-methods does that i can't maintain is the lack > of a common root class for all dao-class instances (in order for the > various update/get/upsert/insert dao methods to get called there will > need to be a dao-object in the hierarchy somewhere). the dao-object > class can be injected in dao-class instance's precedence-list via > compute-class-precedence-list, so there wouldn't be any changes required > to user code; i don't really see this as an issue. > > i would also need to add in a dependency on closer-mop. i could imagine > just cut 'n pasting the, relatively limited, parts of closer-mop we'd > actually be using, and that would keep postmodern's dependencies to what > they are today, but that seems like a bad thing to do. > > since this is a substantial change to how the dao methods are created > i'd like to make sure that there aren't any objects to it (philosophical > or technical) before actually making the change and submitting the pull > request. > > thanks, > -- > -marco >
