[Openmcl-devel] [off-topic] Adding a slot to a class using the MOP
james.anderson at setf.de
Tue Apr 23 02:47:35 PDT 2013
On 2013-04-23, at 09:49 , Hans Hübner wrote:
> On Mon, Apr 22, 2013 at 7:32 PM, Ron Garret <ron at flownet.com> wrote:
> I need to dynamically add a slot to a class using the MOP. There
> doesn't seem to be a standard add-slot method, so I figure I need
> to use something like ensure-class. To do that, I need to
> reconstruct the argument to :direct-slots from the existing class
> definition so I can add a slot without disturbing the existing
> slots. Before I went down this rabbit hole I thought I'd ask: is
> there a better/easier way to do this? Surely I'm not the first
> person to want to do this.
> You are asking for "better/easier" ways, so here are some options:
> - Have your users inherit from a base class that provides the
> default primary key slot, use a slot option and the MOP to give
> users the ability to designate a different slot for the primary key
> (Pascal pointed that out). The MOP will then mostly used to allow
> the extra options.
> - If you dislike the requirement for an explicit common base class,
> modify the class inheritance list of classes using your metaclass
> to include the common base class holding the primary key slot.
> This is not quite as straightforward as it sounds because you'll
> have to find out whether the primary key holding base class is
> already in the ancestor list of a class before you add it.
> - You can also avoid storing the artificial primary key in the
> user's instances altogether by putting it into a (weak) hash table
> keyed by the instance identity. This may actually be the "easiest"
> option, although you stated the requirement that some classes would
> use another slot as their primary key.
> For the first two approaches, maybe https://github.com/slyrus/xml-
> class/blob/master/xml-class.lisp gives you some implementation hints.
> "Adding a slot dynamically" neither sounds like the "best" nor the
> "easiest" option.
the described use case requires to associate identifiers for an
external representation with model instances in such a way that the
association is orthogonal to the model representation and operations.
there are good reasons to support this. for example to provide
retrospectively support for persistence by reachability - that is,
over instances of classes for which the declarations are fixed and
for which extensions are either not desired or infeasible. the
described example illustrates a case where the identifier is atomic -
whether the generated uuid or the declared instance property, but, in
general, such a protocol would also need to support compound or
otherwise computed identifiers, for which no direct representation is
present in the application model.
in this situation, as hans lays out, the alternatives are two. one
can extend the model's internal representation independent of
application definitions. in which case, retrospective capabilities
leave no alternative but to "resort" to mop operations. necessarily
independent of class definitions and likely in definitions managed by
the storage interface. if mop operations is not desired, then the
other alternative is to support the protocol at the interface to the
storage layer independent of the instance representation. either the
store provides for this itself, or one implements it in the access
layer - for example, with the weak hash table approach.
is there another abstract alternative? if not you will have to take
best regards, from berlin,
More information about the Openmcl-devel