Hi,
for convenience I'd like to throw away a class definition during
developement. The class is inherited. If I do the following
(defclass a () ())
(defclass b (a) ())
then
(unintern 'b)
does not solve my problem. b is still a member of (class-direct-subclasses
(find-class 'a)).
Can I get rid of my class 'b?
(Of course I can restart my Lisp, but this is slightly inconvenient)
Thanks
Andreas
Andreas Thiele wrote:
> Hi,
>
> for convenience I'd like to throw away a class definition during
> developement. The class is inherited. If I do the following
>
> (defclass a () ())
>
> (defclass b (a) ())
>
> then
>
> (unintern 'b)
>
> does not solve my problem. b is still a member of (class-direct-subclasses
> (find-class 'a)).
>
> Can I get rid of my class 'b?
(setf (find-class 'b) nil)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Andreas Thiele wrote:
> Wow, speedy answer :)
comp.lang.lisp - Hier werden Sie geholfen! ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
On Sun, 17 Jul 2005 22:33:20 +0200, Pascal Costanza <··@p-cos.net> wrote:
> comp.lang.lisp - Hier werden Sie geholfen! ;)
ROTFL!
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Unfortunately it does not solve my problem, at least not in LispWorks 4.4.
After (setf (find-class 'b) nil)
(find-class 'b) will throw an error but
(class-direct-subclasses (find-class 'a)) still returns class 'b?
Any idea? My classes all belong to a new (my own) metaclass.
Andreas
Andreas Thiele wrote:
> Unfortunately it does not solve my problem, at least not in LispWorks 4.4.
>
> After (setf (find-class 'b) nil)
> (find-class 'b) will throw an error but
> (class-direct-subclasses (find-class 'a)) still returns class 'b?
Right, that's a bug in LispWorks. (I think I have informed them about it
some time ago. Coincidentally, I have fixed that bug in the Closer to
MOP library....)
> Any idea? My classes all belong to a new (my own) metaclass.
Since you define your own metaclass anyway, the following should fix the
problem:
(defmethod reinitialize-instance :before
((class your-metaclass)
&key (direct-superclasses () direct-superclasses-p)
&allow-other-keys)
(when direct-superclasses-p
(loop for superclass in
(copy-list (class-direct-superclasses class))
unless (member superclass direct-superclasses)
do (remove-direct-subclass superclass class))))
I hope this helps.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
"Pascal Costanza" <··@p-cos.net> schrieb im Newsbeitrag
···················@individual.net...
> Andreas Thiele wrote:
> > Unfortunately it does not solve my problem, at least not in LispWorks
4.4.
> >
> > After (setf (find-class 'b) nil)
> > (find-class 'b) will throw an error but
> > (class-direct-subclasses (find-class 'a)) still returns class 'b?
>
> Right, that's a bug in LispWorks. (I think I have informed them about it
> some time ago. Coincidentally, I have fixed that bug in the Closer to
> MOP library....)
>
> > Any idea? My classes all belong to a new (my own) metaclass.
>
> Since you define your own metaclass anyway, the following should fix the
> problem:
>
> (defmethod reinitialize-instance :before
> ((class your-metaclass)
> &key (direct-superclasses () direct-superclasses-p)
> &allow-other-keys)
> (when direct-superclasses-p
> (loop for superclass in
> (copy-list (class-direct-superclasses class))
> unless (member superclass direct-superclasses)
> do (remove-direct-subclass superclass class))))
>
>
> I hope this helps.
>
>
> Pascal
>
> --
> 2nd European Lisp and Scheme Workshop
> July 26 - Glasgow, Scotland - co-located with ECOOP 2005
> http://lisp-ecoop05.bknr.net/
Thanks for the hint and identifying this as error. I will integrate this.
Meanwhile I found a simple solution. I'm writing tests, so I don't care
about the use of eval. I do the following
...
(eval '(defclass b (a) ()))
(code-doing-tests)
(eval '(defclass b () ()))
(setf (find-class 'b) nil)
...
Andreas
Andreas Thiele wrote:
> Meanwhile I found a simple solution. I'm writing tests, so I don't care
> about the use of eval. I do the following
> ...
> (eval '(defclass b (a) ()))
> (code-doing-tests)
> (eval '(defclass b () ()))
> (setf (find-class 'b) nil)
> ...
Neat. You might as well do this:
(defclass b (a) ())
(... tests ...)
(remove-direct-subclass
(find-class 'a) (find-class 'b))
(setf (find-class 'b) nil)
...but that's just nitpicking.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Andreas Thiele wrote:
>> After (setf (find-class 'b) nil)
>> (find-class 'b) will throw an error but
>> (class-direct-subclasses (find-class 'a)) still returns class 'b?
>
> Right, that's a bug in LispWorks.
Why is that a bug? CLHS says SETF of FIND-CLASS does not affect
the class object itself, so I'll be surprised if its relations to
other classes should regardless be affected.
After the class B has been thus disconnected from the superclass A,
will instances of B be updated if A is redefined?
If you first construct an anonymous class with the MOP, and
then associate it with a symbol by calling SETF FIND-CLASS and
immediately remove the association, do you think the subclass
relationship should be broken too?
Kalle Olavi Niemitalo wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Andreas Thiele wrote:
>>
>>>After (setf (find-class 'b) nil)
>>>(find-class 'b) will throw an error but
>>>(class-direct-subclasses (find-class 'a)) still returns class 'b?
>>
>>Right, that's a bug in LispWorks.
>
> Why is that a bug? CLHS says SETF of FIND-CLASS does not affect
> the class object itself, so I'll be surprised if its relations to
> other classes should regardless be affected.
OK, you're absolutely right. Which means that my suggestion to use
remove-direct-subclass directly is also dangerous.
Andreas's response made me check his statement against the list of bugs
I have found in various MOP implementations, but I haven't checked
carefully enough. The bug appears in LispWorks when one changes the list
of direct superclasses:
CL-USER 5 > (defclass a () ())
#<STANDARD-CLASS A 100C20CB>
CL-USER 6 > (defclass b (a) ())
#<STANDARD-CLASS B 1008E4DF>
CL-USER 7 > (reinitialize-instance
(find-class 'b)
:direct-superclasses '())
#<STANDARD-CLASS B 1008E4DF>
CL-USER 8 > (clos:class-direct-subclasses (find-class 'a))
(#<STANDARD-CLASS B 10C6639F>)
CL-USER 9 > (clos:class-direct-superclasses (find-class 'b))
NIL
But you're right, this has nothing to do with changing the name of a
class. Sorry for the fuzz. (At least, Andreas has found a good working
solution for his problem...)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Kalle Olavi Niemitalo wrote:
>
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> Andreas Thiele wrote:
>>>
>>>> After (setf (find-class 'b) nil)
>>>> (find-class 'b) will throw an error but
>>>> (class-direct-subclasses (find-class 'a)) still returns class 'b?
>>>
>>> Right, that's a bug in LispWorks.
>>
>> Why is that a bug? CLHS says SETF of FIND-CLASS does not affect
>> the class object itself, so I'll be surprised if its relations to
>> other classes should regardless be affected.
>
> OK, you're absolutely right. Which means that my suggestion to use
> remove-direct-subclass directly is also dangerous.
...and that my first reply to use (setf (find-class 'b) nil) was wrong
in the first place. *sigh*
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Andreas Thiele wrote:
> > Hi,
> > for convenience I'd like to throw away a class definition during
> > developement. The class is inherited. If I do the following
> > (defclass a () ())
> > (defclass b (a) ())
> > then
> > (unintern 'b)
> > does not solve my problem. b is still a member of
> > (class-direct-subclasses
> > (find-class 'a)).
> > Can I get rid of my class 'b?
>
> (setf (find-class 'b) nil)
That doesn't get rid of the class, it gets rid of the association between
the symbol name and the class.
"... if the new class given to setf is nil, the class association is removed
(but the class object itself is not affected). ..."
http://www.lispworks.com/documentation/HyperSpec/Body/f_find_c.htm#find-class
In general I don't recommend using DEFCLASS "not at toplevel", but the
following may be instructive for testing:
(let ((c1 (defclass c1 () ()))
(c2 (defclass c2 (c1) ())))
(list c1 c2
(find-class 'c1 nil) (find-class 'c2 nil)
(setf (find-class 'c2) nil)
(find-class 'c1 nil) (find-class 'c2 nil)
(class-direct-subclasses c1)
(equal (class-direct-subclasses c1) (list c2))))
=> (#<STANDARD-CLASS C1 205F1734> #<STANDARD-CLASS C2 205F1E24>
#<STANDARD-CLASS C1 205F1734> #<STANDARD-CLASS C2 205F1E24>
NIL
#<STANDARD-CLASS C1 205F1734> NIL
(#<STANDARD-CLASS C2 205F1E24>)
T)
Note that the "name for debugging" of a class is still visible in the
print names above, but that CLOS itself doesn't really connect indirect
through symbols so a class without a name association might be described
as an "uninterned class".
I don't think there's a way in the part of CLOS that's in ANSI CL to
actually remove a defined class.
I'm curious whether you want this for anything other than
development/debugging. Many implementations provide development/debugging
workarounds to this. It seems to me poor style to be trying to remove
classes at runtime, and equally poor style to be caring what the classes
are in someone's direct subclasses. That's a lot like worrying that the
SYMBOL-PLIST of a symbol is or is not NIL. (You own the properties of a
symbol you put there but it's none of your business if someone else has
put some there.)
"Kent M Pitman" <······@nhplace.com> schrieb im Newsbeitrag
··················@nhplace.com...
> Pascal Costanza <··@p-cos.net> writes:
>
> > Andreas Thiele wrote:
> > > Hi,
> > > for convenience I'd like to throw away a class definition during
> > > developement. The class is inherited. If I do the following
> > > (defclass a () ())
> > > (defclass b (a) ())
> > > then
> > > (unintern 'b)
> > > does not solve my problem. b is still a member of
> > > (class-direct-subclasses
> > > (find-class 'a)).
> > > Can I get rid of my class 'b?
> >
> > (setf (find-class 'b) nil)
>
> That doesn't get rid of the class, it gets rid of the association between
> the symbol name and the class.
>
> "... if the new class given to setf is nil, the class association is
removed
> (but the class object itself is not affected). ..."
>
>
http://www.lispworks.com/documentation/HyperSpec/Body/f_find_c.htm#find-clas
s
>
> In general I don't recommend using DEFCLASS "not at toplevel", but the
> following may be instructive for testing:
>
> (let ((c1 (defclass c1 () ()))
> (c2 (defclass c2 (c1) ())))
> (list c1 c2
> (find-class 'c1 nil) (find-class 'c2 nil)
> (setf (find-class 'c2) nil)
> (find-class 'c1 nil) (find-class 'c2 nil)
> (class-direct-subclasses c1)
> (equal (class-direct-subclasses c1) (list c2))))
> => (#<STANDARD-CLASS C1 205F1734> #<STANDARD-CLASS C2 205F1E24>
> #<STANDARD-CLASS C1 205F1734> #<STANDARD-CLASS C2 205F1E24>
> NIL
> #<STANDARD-CLASS C1 205F1734> NIL
> (#<STANDARD-CLASS C2 205F1E24>)
> T)
>
> Note that the "name for debugging" of a class is still visible in the
> print names above, but that CLOS itself doesn't really connect indirect
> through symbols so a class without a name association might be described
> as an "uninterned class".
>
> I don't think there's a way in the part of CLOS that's in ANSI CL to
> actually remove a defined class.
> ...
I wonder a little about such a restriction. The dynamic nature of CLOS is
one thing I especially like about lisp. I can add and remove slots during
runtime without thinking about existing instances, just by re-evaluating the
class definition. I actually do this during development only.
> ...
> I'm curious whether you want this for anything other than
> development/debugging.
> ...
I wanted this for development/debugging only, nothing else.
> ...
> Many implementations provide development/debugging
> workarounds to this.
> ...
Yes, Edi pointed me to my implementations features.
> ...
> It seems to me poor style to be trying to remove
> classes at runtime,
> ...
I hope your statement is too common. Two things:
One of Lisps success stories was a mars missing. They fixed a bug when the
Lisp process was some million miles away from earth. What if this bug was a
class definition which should be removed? I assume, they couldn't restart
the Lisp process.
The system I am working on, mostly is a CLOS centered development system. A
developer might get into a situation when a class is not needed anymore. It
is not convenient if he has to reload the whole system just to get rid of a
class definition.
> ... and equally poor style to be caring what the classes
> are in someone's direct subclasses.
> ...
I also hope this statement is too common. Basically I am mapping object
orientation (CLOS) to entity relation (ER/SQL) databases. This mapping is
different from CL-SQL. A classes direct slots are stored in the classes
table. An extended CLOS class definitions holds all information describing
the required database. This information is derived via MOP. So, I think I
have a strong need to care for reading information regarding class
inheritance.
> ...
> That's a lot like worrying that the
> SYMBOL-PLIST of a symbol is or is not NIL. (You own the properties of a
> symbol you put there but it's none of your business if someone else has
> put some there.)
Kent,
sorry, the mars mission was no good example. Nobody needs to get rid of a class. Changing
inheritance should be sufficient. I just wanted to get rid of the class's mapping into the database
which can be achieved by changing the metaclass from my 'DB-CLASS to 'STANDARD-CLASS.
Andreas
"Andreas Thiele" <··········@nospam.com> writes:
> > I don't think there's a way in the part of CLOS that's in ANSI CL to
> > actually remove a defined class.
> > ...
>
> I wonder a little about such a restriction. The dynamic nature of CLOS is
> one thing I especially like about lisp. I can add and remove slots during
> runtime without thinking about existing instances, just by re-evaluating the
> class definition. I actually do this during development only.
There is no "restriction". It is a "limitation".
The difference is subtle but important. Implementations are expected to
include a MOP or other extensions, and it's assumed that what you want will
be in there.
There is a difference between the language failing to include a way to do
something and the language telling you that you are forbidden from doing
it (and hence that implementations are forbidden to help you).
> > It seems to me poor style to be trying to remove
> > classes at runtime,
> > ...
>
> I hope your statement is too common. Two things:
> One of Lisps success stories was a mars missing. They fixed a bug when the
> Lisp process was some million miles away from earth. What if this bug was a
> class definition which should be removed? I assume, they couldn't restart
> the Lisp process.
A class definition can be redefined, but often it's not necessary.
I didn't say it was bad style to redefine something, I said it was bad
style to assume you could universally quantify over the structure of
the class hierarchy that you yourself didn't define. You originally
reported the problem as if it were a problem to you that
(length (class-direct-subclasses x))
wasn't to your liking. That's not something you are meant to care about.
A reasonable concern for a specific application like the Mars mission would
be more complete redefinability. I've seen this in some specific other
commercial applications as well. But it's NOT the case that all applications
need this. And it is therefore not the case that all applications are
crippled by the absence of this.
The reason I asked whether you need it for other than debugging was to
confirm my (and others') personal informal stats-taking on this. If it
turned out that people needed this a lot, maybe something would change
in the future. But to my knowledge there are only occasional isolated
systems that need this at runtime, and those applications are all
well-served by implementation extensions. Those applications definitely
CANNOT tolerate "just any old CL" for myriad other reasons not related
to what you just remarked on.
> The system I am working on, mostly is a CLOS centered development system. A
> developer might get into a situation when a class is not needed anymore. It
> is not convenient if he has to reload the whole system just to get rid of a
> class definition.
This is a meta-operation that still is not needed in normal programs.
Not all CL implementations seek to do this, and the issue for the CL
design was that the entire community should not be burdened for what
only some wanted to do. CLOS was very experimental initially and we
didn't have a clear idea of where to draw the line. Some wanted all
of the MOP in the language, for example. And there's motivation for
that. But the point is that the MOP and other extensions are there
in most implementations, so just use one of those and use the extended
functionality you need. I don't see a problem.
> > ... and equally poor style to be caring what the classes
> > are in someone's direct subclasses.
> > ...
>
> I also hope this statement is too common. Basically I am mapping object
> orientation (CLOS) to entity relation (ER/SQL) databases. This mapping is
> different from CL-SQL. A classes direct slots are stored in the classes
> table. An extended CLOS class definitions holds all information describing
> the required database. This information is derived via MOP. So, I think I
> have a strong need to care for reading information regarding class
> inheritance.
I still don't see reason for you to care that all classes belong to you,
that all classes are still being used, that the number of classes is some
specific number, etc.
> > ...
> > That's a lot like worrying that the
> > SYMBOL-PLIST of a symbol is or is not NIL. (You own the properties of a
> > symbol you put there but it's none of your business if someone else has
> > put some there.)
"Kent M Pitman" <······@nhplace.com> schrieb im Newsbeitrag
··················@nhplace.com...
> "Andreas Thiele" <··········@nospam.com> writes:
>
> ...
> I still don't see reason for you to care that all classes belong to you,
> that all classes are still being used, that the number of classes is some
> specific number, etc.
> ...
Sorry, this is a misunderstanding, maybe because I'm no native english
speaker. I only care for classes which belong to my metaclass. If there are
classes which want to be superclass of or want to be inherited from my
metaclass my metaclass has to consider this. I'm also not interested in any
specific number of classes. But I am interested in the class precedence list
in some rare cases. I thought you'd consider this as poor style.
Andreas
On Sun, 17 Jul 2005 22:18:20 +0200, "Andreas Thiele" <······@nospam.com> wrote:
> for convenience I'd like to throw away a class definition during
> developement. The class is inherited. If I do the following
>
> (defclass a () ())
>
> (defclass b (a) ())
>
> then
>
> (unintern 'b)
>
> does not solve my problem. b is still a member of
> (class-direct-subclasses (find-class 'a)).
>
> Can I get rid of my class 'b?
Pascal has already showed you a way to do it. But as you are a
LispWorks user you should note that the IDE offers the general option
to "undefine" things - this'll also work for DEFCLASS.
Search for "Undefine" in the Editor User Guide and the Common
LispWorks User Guide.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Edi Weitz" <········@agharta.de> schrieb im Newsbeitrag
··················@agharta.de...
> On Sun, 17 Jul 2005 22:18:20 +0200, "Andreas Thiele" <······@nospam.com>
wrote:
>
> > for convenience I'd like to throw away a class definition during
> > developement. The class is inherited. If I do the following
> >
> > (defclass a () ())
> >
> > (defclass b (a) ())
> >
> > then
> >
> > (unintern 'b)
> >
> > does not solve my problem. b is still a member of
> > (class-direct-subclasses (find-class 'a)).
> >
> > Can I get rid of my class 'b?
>
> Pascal has already showed you a way to do it. But as you are a
> LispWorks user you should note that the IDE offers the general option
> to "undefine" things - this'll also work for DEFCLASS.
>
> Search for "Undefine" in the Editor User Guide and the Common
> LispWorks User Guide.
>
> Cheers,
> Edi.
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Thanks Edi,
I know, but I'd like to have this under program control for automating
tests.
Andreas
On Sun, 17 Jul 2005 22:54:51 +0200, "Andreas Thiele" <······@nospam.com> wrote:
> I know, but I'd like to have this under program control for
> automating tests.
(editor::undefine-one-dspec '(defclass b))
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Edi Weitz" <········@agharta.de> schrieb im Newsbeitrag
··················@agharta.de...
> On Sun, 17 Jul 2005 22:54:51 +0200, "Andreas Thiele" <······@nospam.com>
wrote:
>
> > I know, but I'd like to have this under program control for
> > automating tests.
>
> (editor::undefine-one-dspec '(defclass b))
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Just didn't see this. Thanks for keeping me from to much RTFM :))
Andreas
On Sun, 17 Jul 2005 23:32:08 +0200, "Andreas Thiele" <······@nospam.com> wrote:
> Just didn't see this. Thanks for keeping me from to much RTFM :))
Well, it's not in the manual but it was easy to find with
C-h s unde TAB RET
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Sun, 17 Jul 2005 23:39:15 +0200, Edi Weitz <········@agharta.de> wrote:
> Well, it's not in the manual
Correction: It /is/ in the manual.
<http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-137.htm>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")