on removing build-dao-methods

[Marco Baringer]

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