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,