[Prev][Next][Index][Thread]
Re: Dylan, MOP, object/relational mapping...
You can macro up the auto-generated classes/methods. The macro can inline any
custom code into the default code in a meaningful way.
The add-slot method got taken out after the interim DRM, I think. :-)
Control and export of methods is handled in the "define module" part of your
export library file.
- Rob.
Scott Ribe wrote:
> 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!
References: