From: Sam Steingold
Subject: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <m3vfxv6jbf.fsf@loiso.podval.org>
Suppose a class was redefined twice (i.e., defined once and then
redefined two times) but an instance created before the first
redefinition was first accessed after the second one.
The question is, how many times update-instance-for-redefined-class
will be called for this instance?
Just once (going from the original - first - definition to the latest -
third - one) or twice (first going from the first/original definition to
the first redefinition, i.e., the second definition, and the second
time, going from the second definition to the final, third one)?
Obviously, if the instance was accessed before the second redefinition,
then update-instance-for-redefined-class will be called twice.
What if the instance was _not_ accessed until the second redefinition?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
He who laughs last thinks slowest.

From: Barry Margolin
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <1Ghja.4$cO1.560@paloalto-snr1.gtei.net>
In article <··············@loiso.podval.org>,
Sam Steingold  <···@gnu.org> wrote:
>Suppose a class was redefined twice (i.e., defined once and then
>redefined two times) but an instance created before the first
>redefinition was first accessed after the second one.
>The question is, how many times update-instance-for-redefined-class
>will be called for this instance?
>Just once (going from the original - first - definition to the latest -
>third - one) or twice (first going from the first/original definition to
>the first redefinition, i.e., the second definition, and the second
>time, going from the second definition to the final, third one)?
>Obviously, if the instance was accessed before the second redefinition,
>then update-instance-for-redefined-class will be called twice.
>What if the instance was _not_ accessed until the second redefinition?

I think either is possible.

The standard says that U-I-F-R-C is called no later than the first time an
instance is accessed after the redefinition, but it may be called earlier.
A possible implementation is to call it on all the instances of the class
at the time of the redefinition.

If you redefine a class multiple times, I think you should write your
U-I-F-R-C methods to be able to handle any combination of updates that
could result.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Sam Steingold
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <m38yuq6wm4.fsf@loiso.podval.org>
> * In message <···············@paloalto-snr1.gtei.net>
> * On the subject of "Re: repeated class redefinition and update-instance-for-redefined-class"
> * Sent on Fri, 04 Apr 2003 15:38:37 GMT
> * Honorable Barry Margolin <··············@level3.com> writes:
>
> In article <··············@loiso.podval.org>,
> Sam Steingold  <···@gnu.org> wrote:
> >Suppose a class was redefined twice (i.e., defined once and then
> >redefined two times) but an instance created before the first
> >redefinition was first accessed after the second one.
> >The question is, how many times update-instance-for-redefined-class
> >will be called for this instance?
> >Just once (going from the original - first - definition to the latest -
> >third - one) or twice (first going from the first/original definition to
> >the first redefinition, i.e., the second definition, and the second
> >time, going from the second definition to the final, third one)?
> >Obviously, if the instance was accessed before the second redefinition,
> >then update-instance-for-redefined-class will be called twice.
> >What if the instance was _not_ accessed until the second redefinition?
> 
> I think either is possible.
> 
> The standard says that U-I-F-R-C is called no later than the first time an
> instance is accessed after the redefinition, but it may be called earlier.
> A possible implementation is to call it on all the instances of the class
> at the time of the redefinition.
> 
> If you redefine a class multiple times, I think you should write your
> U-I-F-R-C methods to be able to handle any combination of updates that
> could result.

I guess I was not clear enough.  Sorry.
I am asking from the position of the implementor, not the user.
U-I-F-R-C will be called only when the instance is accessed, not before.
The question is: when there were multiple redefinitions, do I call
U-I-F-R-C once or many times?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
The only intuitive interface is the nipple.  The rest has to be learned.
From: Barry Margolin
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <YWija.11$cO1.969@paloalto-snr1.gtei.net>
In article <··············@loiso.podval.org>,
Sam Steingold  <···@gnu.org> wrote:
>I guess I was not clear enough.  Sorry.
>I am asking from the position of the implementor, not the user.
>U-I-F-R-C will be called only when the instance is accessed, not before.
>The question is: when there were multiple redefinitions, do I call
>U-I-F-R-C once or many times?

The standard doesn't say one way or the other, AFAIK, so I think either way
is conforming.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: james anderson
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <3E8E1C75.ADD5893@setf.de>
Barry Margolin wrote:
> 
> In article <··············@loiso.podval.org>,
> Sam Steingold  <···@gnu.org> wrote:
> >I guess I was not clear enough.  Sorry.
> >I am asking from the position of the implementor, not the user.
> >U-I-F-R-C will be called only when the instance is accessed, not before.
> >The question is: when there were multiple redefinitions, do I call
> >U-I-F-R-C once or many times?
> 
> The standard doesn't say one way or the other, AFAIK, so I think either way
> is conforming.

while either way is conforming, what would be the reasons to perform U-I-F-R-C agressively?

arguments for doing it lazily are easy enough to conceive. in general, that it
parallels the behaviour of classes during a "definition phass". in particular,
that it allows intermediate states which are inconsistent or incomplete, so
long as a consistent state is achieved before an instance is referenced. 

are there cases which argue for doing it agressively?

...
From: Kent M Pitman
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <sfwpto1zr90.fsf@shell01.TheWorld.com>
james anderson <··············@setf.de> writes:

> are there cases which argue for doing it agressively?

Sure.  Because that's the only way you can do it correctly. ;)

The method makes use of knowledge of the before state and the after state.
If you wait until you change the after state, the method might not perform
correctly any more.

This is a part of the design of CL that I was not directly involved in,
but I would _expect_ the advice to be to do it aggressively if the
implementation wants to.  Certainly there might be reasons (paging 
performance is one and lack of ability to enumerate the instances is
another) for not doing it aggressively, but those seem the substandard
case.

Indeed, if you redefined a class several time and wrote a method each
time for how to update it, you'd think that it would be possible to chain
through the classes and apply each of the interim methods in order to
bring things up to date.  I certainly would _not_ apply the same method
over and over.
From: Barry Margolin
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <91pja.28$cO1.1740@paloalto-snr1.gtei.net>
In article <················@setf.de>,
james anderson  <··············@setf.de> wrote:
>
>
>Barry Margolin wrote:
>> 
>> In article <··············@loiso.podval.org>,
>> Sam Steingold  <···@gnu.org> wrote:
>> >I guess I was not clear enough.  Sorry.
>> >I am asking from the position of the implementor, not the user.
>> >U-I-F-R-C will be called only when the instance is accessed, not before.
>> >The question is: when there were multiple redefinitions, do I call
>> >U-I-F-R-C once or many times?
>> 
>> The standard doesn't say one way or the other, AFAIK, so I think either way
>> is conforming.
>
>while either way is conforming, what would be the reasons to perform
>U-I-F-R-C agressively?
>
>arguments for doing it lazily are easy enough to conceive. in general, that it
>parallels the behaviour of classes during a "definition phass". in particular,
>that it allows intermediate states which are inconsistent or incomplete, so
>long as a consistent state is achieved before an instance is referenced. 
>
>are there cases which argue for doing it agressively?

Doing it lazily means that every instance has to have a flag indicating
whether it has been updated, and every use of an instance has to check the
flag.  This is overhead that must be paid whether or not you ever redefine
classes.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: james anderson
Subject: Re: repeated class redefinition and update-instance-for-redefined-class
Date: 
Message-ID: <3E8ECACA.BF3FBBB0@setf.de>
Barry Margolin wrote:
> 
> In article <················@setf.de>,
> james anderson  <··············@setf.de> wrote:
> >
> >
> ...
> >
> >are there cases which argue for doing it agressively?
> 
> Doing it lazily means that every instance has to have a flag indicating
> whether it has been updated, and every use of an instance has to check the
> flag.  This is overhead that must be paid whether or not you ever redefine
> classes.
> 

is that very different from the situation with forward reference classes in general.

Kent M Pitman wrote:
> 
> james anderson <··············@setf.de> writes:
> 
> > are there cases which argue for doing it agressively?
> 
> Sure.  Because that's the only way you can do it correctly. ;)
> 
> The method makes use of knowledge of the before state and the after state.
> If you wait until you change the after state, the method might not perform
> correctly any more.
> 

it's not update-instance-for-redefined-class, itself, which would concern me.

it's more a matter of shared-initialize, which in some cases could have been
written to depend on constraints which are violated in the course of changes
to multiple classes (whether slot definitions or precedence) and are upheld
only in the state after all of the redefinitions have been accomplished. doing
the calls agressively means that one cannot proceed as "naively" as on can
with definition, so something like the following would likely fail:


(defclass line ()
  ((start :initarg :start :reader line-start)
   (end :initarg :end :reader line-end)
   (tlbr )))

(defMethod shared-initialize :after ((instance line) (slots t)
                                     &key &allow-other-keys)
  (with-slots (start end tlbr) instance
    (setf tlbr (list (min (point-v start) (point-v end))
                     (min (point-h start) (point-h end))
                     (max (point-v start) (point-v end))
                     (max (point-h start) (point-h end))))))

(defMethod print-object ((line line) stream)
  (with-slots (start end tlbr) line
    (print-unreadable-object (line stream :type t)
      (format stream "~a,~a [~{~d ~d ~d ~d~}]"
              (point-string start) (point-string end) tlbr))))

(defParameter *line* (make-instance 'line :start ·@(0 0) :end ·@(100 100)))
*line*

(defclass line (figure)
  ((start :initarg :start :reader line-start)
   (end :initarg :end :reader line-end)
   ))

(defClass circle (figure)
  ((center :initarg :center :reader circle-center)
   (radius :initarg :radius :reader circle-radius)))

(defMethod print-object ((figure circle) stream)
  (with-slots (center radius tlbr) figure
    (print-unreadable-object (figure stream :type t)
      (format stream "~a,~a [~{~d ~d ~d ~d~}]"
              (circle-center figure) (circle-radius figure) tlbr))))

(defMethod shared-initialize :after ((instance circle) (slots t)
                                     &key &allow-other-keys)
  (with-slots (center radius tlbr) instance
    (let ((delta (* radius (cos (/ pi 4)))))
      (setf tlbr (list (- (point-v center) delta)
                       (- (point-v center) delta)
                       (+ (point-v center) delta)
                       (+ (point-v center) delta))))))

(defClass figure ()
  ((tlbr )))

(defParameter *line* (make-instance 'line :start ·@(0 0) :end ·@(100 100)))
*line*

(defParameter *circle* (make-instance 'circle :center ·@(0 0) :radius 1))
*circle* 


...