[Prev][Next][Index][Thread]

Re: Dylan, MOP, object/relational mapping...


Yet another alternative comes to mind:

Check for a custom class corresponding to an entity, if the class does
not exist, create it along with slots and accessors. The DRM doesn't
(seem to) contain enough detail for me to figure out whether this will
really work. Either individual slots must be allocated for each
attribute (which I think is OK) with the normal auto-generated accessor
methods, or the attributes will map to virtual slots with accessor
methods that perform lookup into an attributes dictionary.

Now, this satisfies most of my desiderata. The only "gotcha" is that the
class is completely auto-generated or completely custom. Therefore if
any attribute of a class requires a custom accessor, then a class must
be provided which implements all accessors.

Perhaps this could be worked around by using two classes. Define an
abstract class that implements the custom accessors (and other custom
behavior), then at runtime from the metadata generate a concrete class
that inherits from the custom one, and adds any accessors not
implemented by the custom class. That dynamically generated custom class
would be the one used by all client software.

The question is, will this really work? Can I really create a new class
at runtime, with a slot with a name that was not ever seen by the
compiler, and expect that Dylan will add the generic function and method
as needed to get the accessors to work? Or will the fact that I called
object.foo somewhere in the code, without ever defining a getter for
foo, cause there to already be an empty generic function generated, so
that the dynamically added class can create a new foo getter and add it
to the gf? Or will something just blow up in my face? If that works,
what if object.foo is never actually called, because the client code
does not use that attribute, then will it fail because there is no
generic function to add to? Or will it create an anonymous gf that will
(can) never be called?

Even if it does work, how does one control export and visibility of the
accessor functions? If the point is to avoid writing the accessor
functions for the cases where they don't do anything special, it would
seem to be much less useful if I then had to explicitly export those
accessors that I didn't have to write!

Maybe I'm barking up the wrong tree...