Programmatically adding a slot to a class
in [Lisp]
|
Prev: A link to a collection of tutorials on LISP.
Next: Can elisp call C functions without recompilation of emacs?
From: Robert Swindells on 29 Jun 2010 08:00 On Tue, 29 Jun 2010 13:28:51 +0200, Pascal Costanza wrote: > On 29/06/2010 12:49, Robert Swindells wrote: >> On Tue, 29 Jun 2010 11:46:12 +0200, Pascal Costanza wrote: >> >>> It should be relatively easy for a GUI-based tool to construct >>> defclass forms from user input, right? >> >> I have a copy of a paper that describes the LeLisp version of the >> interface builder and saw Jean-Marie Hullot give a presentation and >> demo of ExperInterfaceBuilder. >> >> My reading of the paper is that most of the Editors were operating on >> instances of pre-defined classes, not defining new classes, I think it >> would require a reading of the documentation on the object system used >> (Alcyone) to be sure though. > > Do you have a reference? Not really, "SOS Interface, Un générateur d'Interfaces Homme - Machine" from "Journées Langages Orientés Objet" no date. I got it as a photocopy. Robert Swindells
From: Robert Swindells on 29 Jun 2010 08:01 On Tue, 29 Jun 2010 04:34:58 -0700, joswig(a)corporate-world.lisp.de wrote: > On 29 Jun., 13:28, Pascal Costanza <p...(a)p-cos.net> wrote: >> On 29/06/2010 12:49, Robert Swindells wrote: >> >> > On Tue, 29 Jun 2010 11:46:12 +0200, Pascal Costanza wrote: >> >> >> It should be relatively easy for a GUI-based tool to construct >> >> defclass forms from user input, right? >> >> > I have a copy of a paper that describes the LeLisp version of the >> > interface builder and saw Jean-Marie Hullot give a presentation and >> > demo of ExperInterfaceBuilder. >> >> > My reading of the paper is that most of the Editors were operating on >> > instances of pre-defined classes, not defining new classes, I think >> > it would require a reading of the documentation on the object system >> > used (Alcyone) to be sure though. >> >> Do you have a reference? > > There is a bit of Alcyone here, but not in depth: > > http://hal.archives-ouvertes.fr/docs/00/07/00/98/PDF/RT-0060.pdf That is the technical report referenced in the paper that I have, thanks. Robert Swindells
From: Scott L. Burson on 29 Jun 2010 17:51 On Jun 29, 2:55 am, Pascal Costanza <p...(a)p-cos.net> wrote: > > (defclass my-class (third-party-class) > ((my-additional-slot ...))) > > (defmethod make-instance ((class (eql 'third-party-class)) &rest args) > (apply #'make-instance 'my-class args)) > > This is not 100% fool-proof, but since your solution is not 100% > fool-proof either, I think I would prefer my solution. A very interesting suggestion, and I see why you like it. I note however that it doesn't compose: you couldn't do this in two places. > > Pascal B's code is working fine for me. Maybe something like this > > belongs in Closer, or in a CLOS utilities library? > > No, because it's really hard to come up with good solutions for the > really tough corner cases. I think it's better to use ad hoc solutions > for the concrete problems you actually have, and the MOP API is good > enough to accommodate this. Fair enough. > > BTW I agree with Rainer -- these situations are not rare at all in my > > experience. For years I used a language called Refine in which slot > > definitions were not part of the class definition but were separate > > top-level syntactic entities. It was therefore trivial, for example, > > to declare a class with some of its slots in one source file, and to > > add additional slots to it in another source file. (There was a way > > to interactively request the entire list of slots, in case one needed > > to know, but this need arose less often than one might expect.) > > > Like a lot of things, this flexibility could be abused, but used > > intelligently it was quite handy. > > Here is another way to achieve what you want: > > (defvar *external-store* (make-weak-hash-table :test #'equal)) > [...] > > Again, not 100% fool-proof, but ANSI-compliant Umm... except for the MAKE-WEAK-HASH-TABLE part :) But yes, in most implementations, this is also a reasonable suggestion. -- Scott
From: Scott L. Burson on 29 Jun 2010 22:05 On Jun 28, 11:58 pm, Christophe Rhodes <cs...(a)cantab.net> wrote: > "Scott L. Burson" <g...(a)zeta-soft.com> writes: > > > On Jun 28, 12:09 am, Pascal Costanza <p...(a)p-cos.net> wrote: > >> On 28/06/2010 01:00, Scott L. Burson wrote: > > >> > For those with more MOP experience than I, what's the easiest way to > >> > programmatically add a slot to an existing class? > > >> The situations were you may want to do this are usually extremely rare.. > >> So it may be useful to tell us what you want to achieve, so we can maybe > >> come up with better solutions. > > > I just wanted to extend a class whose definition I don't control. I > > could just load a patch containing the DEFCLASS form with my slot > > added -- I do have access to the original DEFCLASS form -- but then if > > it changed, I would have to update my patch. Doing it this way makes > > it reasonably upgrade-proof. > > For what it's worth: I'd be tempted to add in a superclass mixin > containing your slot, rather than patch in the slot directly; the effect > is basically the same, but maybe marginally more upgrade-proof? I don't see offhand how it would be any more upgrade-proof. > However, is this not a sign that something somewhere else isn't quite > right? The "normal" way to do this would be to arrange that you use a > subclass of the original class, creating instances of that class and > passing them around In this particular case, that wouldn't be hard. In general, though, it can be more difficult. I think a program organization that allows slot definitions to appear in various locations in the source code could be described as aspect- oriented rather than object-oriented. (I faintly recall that AspectJ (which I have never used but heard a talk about once) has a way to add a slot to a class.) I think it's a valid and sometimes useful way of organizing code, despite the fact that it seems strange and wrong to people used to object-oriented organization. -- Scott
From: Christophe Rhodes on 30 Jun 2010 02:24
"Scott L. Burson" <gyro(a)zeta-soft.com> writes: > On Jun 28, 11:58 pm, Christophe Rhodes <cs...(a)cantab.net> wrote: >> For what it's worth: I'd be tempted to add in a superclass mixin >> containing your slot, rather than patch in the slot directly; the effect >> is basically the same, but maybe marginally more upgrade-proof? > > I don't see offhand how it would be any more upgrade-proof. Ah, I missed out a detail: it's fairly easy to also write a method on the MOP function ENSURE-CLASS-USING-CLASS to make sure that all these extra added superclasses are preserved if and when the original DEFCLASS (without any mention of superclasses) is re-evaluated, say to fix some unrelated problem. (This is a technique used in gsharp, for example). You could probably do something like this with slots, too, but it's somewhat trickier to construct the slot definitions, and a little harder to redefine the added slots (whereas redefining the added mixin classes also "just works"). Christophe |