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: Pascal Costanza on 28 Jun 2010 03:09 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. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: joswig on 28 Jun 2010 05:38 On 28 Jun., 09:09, 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 don't find that rare at all and would hope that adding a slot would be be simpler. That's one of the areas where other object-oriented systems for Lisp were much easier to use. For example in Object Lisp one could write nice tools to edit objects graphically and add/remove slots in a simple way. Every GUI based editor of a class hierarchy wants to manipulate slots. For example in a CAD system where classes describe objects, one may want to edit the classes in a browser. In an interface designer, the triangle-button-class may need another slot. Lisp was developed with a focus on interactive development and over time developers used it to create interactive GUI based applications. A reason that this tradition has been not revived as it should, in that CLOS is very dynamic, but it makes some operations a bit difficult (like dealing with slot information, adding slots, etc.). Garnet used a simple frame system, Sk8 too, the early user interface designer for MCL used a nice view system with prototype objects, ... Another domain where this is heavily used is knowledge representation. CLOS could have been used more widely here. As much as I like CLOS, I think it lost some of the appeal of the earlier systesm - probably because it was less driven by applications and practicality , but slightly more by abstract design considerations. The effect is that editing text based Lisp is easy, but for creating tools, one has to go through more complex code than one may want. Am I a dinosaur with my wish for easy to use tools for interactive computation? Is that out of fashion forever? Maybe I am spoiled by tools that nobody anymore uses? I guess somebody should demo things like Coral Common Lisp 1.0 on a Mac SE/30 at some Lisp user conference to give others a feeling what was possible in Lisp with 2.5 MB of RAM on a 68030. I know the workd has moved on, but it would be nice if we have added capabilities and not lost them. > Pascal > > -- > My website:http://p-cos.net > Common Lisp Document Repository:http://cdr.eurolisp.org > Closer to MOP & ContextL:http://common-lisp.net/project/closer/
From: Pascal Costanza on 28 Jun 2010 08:47 On 28/06/2010 11:38, joswig(a)corporate-world.lisp.de wrote: > On 28 Jun., 09:09, 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 don't find that rare at all and would hope that adding a slot would > be be simpler. > > That's one of the areas where other object-oriented systems for Lisp > were much easier to use. > For example in Object Lisp one could write nice tools to edit objects > graphically > and add/remove slots in a simple way. Every GUI based editor of a > class hierarchy > wants to manipulate slots. For example in a CAD system where classes > describe > objects, one may want to edit the classes in a browser. In an > interface designer, > the triangle-button-class may need another slot. > > Lisp was developed with a focus on interactive development and over > time developers used > it to create interactive GUI based applications. A reason that this > tradition has been not revived as it should, in that CLOS is very > dynamic, but it makes some operations a bit difficult (like dealing > with slot information, adding slots, etc.). Garnet used a simple > frame system, Sk8 too, the early user interface designer for MCL > used a nice view system with prototype objects, ... > > Another domain where this is heavily used is knowledge representation. > CLOS could have been used more widely here. As much as I like CLOS, > I think it lost some of the appeal of the earlier systesm - > probably because it was less driven by applications and practicality > , but slightly more > by abstract design considerations. > > The effect is that editing text based Lisp is easy, but for creating > tools, one > has to go through more complex code than one may want. > > Am I a dinosaur with my wish for easy to use tools for interactive > computation? > Is that out of fashion forever? Maybe I am spoiled by tools > that nobody anymore uses? > > I guess somebody should demo things like Coral Common Lisp 1.0 > on a Mac SE/30 at some Lisp user conference to give others > a feeling what was possible in Lisp with 2.5 MB of RAM > on a 68030. I know the workd has moved on, but it would be nice > if we have added capabilities and not lost them. I haven't been around when all these things happened, so I have my knowledge only from indirect sources. However, as far as I can understand, many of the things that you describe can relatively easily be achieved by using your own custom metaclasses. The default standard-class provides features that were deemed useful for a broad range of scenarios, but more specific features were left for such custom metaclasses. Adding/removing slots is maybe a bit harder than necessary, but certainly possible, and writing a graphical user interface for manipulating classes and their hierarchies doesn't happen that often, does it? So I guess the compromise they made there is ok. Some design choices in CLOS seem to have been motivated by a wish to compete with other object-oriented languages, which due to their restrictions could (and can) be implemented more efficiently. That's maybe a pity indeed. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: joswig on 28 Jun 2010 09:01 On 28 Jun., 14:47, Pascal Costanza <p...(a)p-cos.net> wrote: > On 28/06/2010 11:38, jos...(a)corporate-world.lisp.de wrote: > > > > > > > On 28 Jun., 09:09, 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 don't find that rare at all and would hope that adding a slot would > > be be simpler. > > > That's one of the areas where other object-oriented systems for Lisp > > were much easier to use. > > For example in Object Lisp one could write nice tools to edit objects > > graphically > > and add/remove slots in a simple way. Every GUI based editor of a > > class hierarchy > > wants to manipulate slots. For example in a CAD system where classes > > describe > > objects, one may want to edit the classes in a browser. In an > > interface designer, > > the triangle-button-class may need another slot. > > > Lisp was developed with a focus on interactive development and over > > time developers used > > it to create interactive GUI based applications. A reason that this > > tradition has been not revived as it should, in that CLOS is very > > dynamic, but it makes some operations a bit difficult (like dealing > > with slot information, adding slots, etc.). Garnet used a simple > > frame system, Sk8 too, the early user interface designer for MCL > > used a nice view system with prototype objects, ... > > > Another domain where this is heavily used is knowledge representation. > > CLOS could have been used more widely here. As much as I like CLOS, > > I think it lost some of the appeal of the earlier systesm - > > probably because it was less driven by applications and practicality > > , but slightly more > > by abstract design considerations. > > > The effect is that editing text based Lisp is easy, but for creating > > tools, one > > has to go through more complex code than one may want. > > > Am I a dinosaur with my wish for easy to use tools for interactive > > computation? > > Is that out of fashion forever? Maybe I am spoiled by tools > > that nobody anymore uses? > > > I guess somebody should demo things like Coral Common Lisp 1.0 > > on a Mac SE/30 at some Lisp user conference to give others > > a feeling what was possible in Lisp with 2.5 MB of RAM > > on a 68030. I know the workd has moved on, but it would be nice > > if we have added capabilities and not lost them. > > I haven't been around when all these things happened, so I have my > knowledge only from indirect sources. However, as far as I can > understand, many of the things that you describe can relatively easily > be achieved by using your own custom metaclasses. The default > standard-class provides features that were deemed useful for a broad > range of scenarios, but more specific features were left for such custom > metaclasses. > Fortunately a lot of stuff is possible with the MOP and it is good to have a library that unifies the MOP over implementations. Thanks for that. > Adding/removing slots is maybe a bit harder than necessary, but > certainly possible, and writing a graphical user interface for > manipulating classes and their hierarchies doesn't happen that often, > does it? So I guess the compromise they made there is ok. I think it is absolute crucial if you want to design user interfaces. The first modern UI designer was written in Lisp and later reimplemented at Apple. This UI designer is at the heart of many of the nice applications for the Mac/iPhone/iPad. Basically in any application like this you put some object on the screen and give it some class. Often one would just subclass, say, a button, give that some slots and put a such a button on the screen. Later one might need another slot, add it to the class and the buttons on the screen are changed... I find these are quite common use cases in designing User Interfaces of all kinds. I fear that these use cases come up not that often, because some capabilities needed for that are not obvious in CLOS (though possible) and thus CLOS/CL is less used for that. I fear it is not that these use cases are rare and thus capabilities are not needed (in a straightforward) way. > > Some design choices in CLOS seem to have been motivated by a wish to > compete with other object-oriented languages, which due to their > restrictions could (and can) be implemented more efficiently. That's > maybe a pity indeed. > > Pascal > > -- > My website:http://p-cos.net > Common Lisp Document Repository:http://cdr.eurolisp.org > Closer to MOP & ContextL:http://common-lisp.net/project/closer/
From: Alessio Stalla on 28 Jun 2010 09:09
On Jun 28, 1:00 am, "Scott L. Burson" <g...(a)zeta-soft.com> wrote: > For those with more MOP experience than I, what's the easiest way to > programmatically add a slot to an existing class? IIRC, one of the examples in AMOP was about adding some kind of "dynamic slots" to CLOS. They were implemented as a map stored in a "private" slot, so not as efficient as regular slots, but it can be a start. hth, Alessio |