From: ·············@gmail.com
Subject: Can sub-classes initialize-instance modify base-classes slot *before* 	base's initialize-instance executes?
Date: 
Message-ID: <704974e2-6713-4557-9a0c-8a5c5cb19293@b2g2000prf.googlegroups.com>
I suspect the answer is no, and in which case I will revisit my
concept.  But here is the story.

I have a base class that initializes storage.  One of its subclasses
needs extra padding around the storage.  The base classes initializes
the padding to zero, and the subclasses ought to change that.  Is
there some way to specify this within the standard CLOS machinery?

Here is the example code:

(in-package :cl-user)

(defclass base ()
  ((dim
    :initform 12
    :accessor dim)
   (padding
    :initform 0
    :accessor padding
    :initarg :padding
    :documentation "Padding is necessary for some higher order
interpolations")
   (storage
    :initform nil
    :accessor storage)))
(defmethod initialize-instance :after ((this base) &key)
  (format t "Initializing base ~a~%" this)
  (setf (storage this) (make-array (+ (dim this)
				      (padding this))
				   :initial-element 0d0)))

(defclass sub1a (base)
  ((dummy
    :initform 2d0
    :accessor dummy))
 (:documentation "This will implement a higher order interpolations
that needs padding")

;; I would like to modify padding here.
(defmethod initialize-instance :after ((this sub1a) &key)
  (format t "Initializing sub ~a~%" this)
  (setf (padding this) 2))


To get what I want, I need to do
> (make-instance 'sub1a :padding 2)
but I would prefer to do just
> (make-instance 'sub1a)
This, of course does not work, because first the base's initialize-
instance method is called, which sort-of makes sense.

The first approach looks kind of kludgy, even though Keene (yep, I
went to the library and got the CLOS book) suggests using constructors
to hide the ugly make-instance details.

In real world, the base class is a an "abstract/virtual" (not sure of
the difference) class for a differential equation solver, while the
(layered) subclasses are particular instances of the solvers, some of
which build on top of others.  The base class provides the basic
storage, and methods for storing, accessing, and numerical
computations.

Thanks,

Mirko

From: Kenny
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before*  base's initialize-instance executes?
Date: 
Message-ID: <48ee640b$0$5646$607ed4bc@cv.net>
·············@gmail.com wrote:
> I suspect the answer is no, and in which case I will revisit my
> concept.  But here is the story.
> 
> I have a base class that initializes storage.  One of its subclasses
> needs extra padding around the storage.  The base classes initializes
> the padding to zero, and the subclasses ought to change that.  Is
> there some way to specify this within the standard CLOS machinery?
> 
> Here is the example code:
> 
> (in-package :cl-user)
> 
> (defclass base ()
>   ((dim
>     :initform 12
>     :accessor dim)
>    (padding
>     :initform 0
>     :accessor padding
>     :initarg :padding
>     :documentation "Padding is necessary for some higher order
> interpolations")
>    (storage
>     :initform nil
>     :accessor storage)))
> (defmethod initialize-instance :after ((this base) &key)
>   (format t "Initializing base ~a~%" this)
>   (setf (storage this) (make-array (+ (dim this)
> 				      (padding this))
> 				   :initial-element 0d0)))
> 
> (defclass sub1a (base)
>   ((dummy
>     :initform 2d0
>     :accessor dummy))
>  (:documentation "This will implement a higher order interpolations
> that needs padding")
> 
> ;; I would like to modify padding here.
> (defmethod initialize-instance :after ((this sub1a) &key)
>   (format t "Initializing sub ~a~%" this)
>   (setf (padding this) 2))
> 
> 
> To get what I want, I need to do
> 
>>(make-instance 'sub1a :padding 2)
> 
> but I would prefer to do just
> 
>>(make-instance 'sub1a)
> 
> This, of course does not work, ...

I wish you had proved that with repl output...oh, christ, you are not 
talking about padding, you are talking about the storage. Which takes me 
back to your use of "This" which in turn takes me back to high school 
geometry and Mr. Wiseman who always said "There's no room for pronouns 
in geometry, Mr. Tilton.

> because first the base's initialize-
> instance method is called, which sort-of makes sense.

That One will be along shortly to recommend either a metaclass or 
AspectL, I will recommend Cells which always does things In the Right 
Order(tm). And happily saves you from having to write i-i methods, that 
name is too long and I have carpal tunnel, dammit! I digress.

A humbler "gee, let's do everything with CLOS!" solution would be to use 
an :around method to set up the storage slot, doing so /after/ 
call-next-method to get the desired effect.

But now we have the CLOS tail wagging the dog, which I am afraid is you. 
  What happens when things get more complicated and you run out of 
stupid GF dispatch tricks? /Now/ we need That One. Or Cells.

Interestingly, Cells was invented precisely to solve a problem with 
order of calculation -- one where slots needed the value of slots from 
other instances as well as the same -- not to do reactive programming 
(the handiest name for this particular pet trick). Reactive just fell 
out of the tree, which was the second sign to me that Cells was way 
cool. The first was how it trivially dispatched the daunting problem of 
getting complex gui geometry calculated in the right order.


> 
> The first approach looks kind of kludgy, even though Keene (yep, I
> went to the library and got the CLOS book) suggests using constructors
> to hide the ugly make-instance details.

She was simply wrong. That breaks the usefulness of generic dispatch.

> 
> In real world, the base class is a an "abstract/virtual" (not sure of
> the difference) class for a differential equation solver, while the
> (layered) subclasses are particular instances of the solvers, some of
> which build on top of others.  The base class provides the basic
> storage, and methods for storing, accessing, and numerical
> computations.

Do I tell you my problems? :)

hth,kzo
From: ·············@gmail.com
Subject: Re: Can sub-classes initialize-instance modify base-classes slot 	*before* base's initialize-instance executes?
Date: 
Message-ID: <0f7db29a-449c-4d2e-b4d2-d4b7dd19a899@v53g2000hsa.googlegroups.com>
On Oct 9, 4:05 pm, Kenny <·········@gmail.com> wrote:
> ·············@gmail.com wrote:
> > I suspect the answer is no, and in which case I will revisit my
> > concept.  But here is the story.
>
> > I have a base class that initializes storage.  One of its subclasses
> > needs extra padding around the storage.  The base classes initializes
> > the padding to zero, and the subclasses ought to change that.  Is
> > there some way to specify this within the standard CLOS machinery?
>
> > Here is the example code:
>
> > (in-package :cl-user)
>
> > (defclass base ()
> >   ((dim
> >     :initform 12
> >     :accessor dim)
> >    (padding
> >     :initform 0
> >     :accessor padding
> >     :initarg :padding
> >     :documentation "Padding is necessary for some higher order
> > interpolations")
> >    (storage
> >     :initform nil
> >     :accessor storage)))
> > (defmethod initialize-instance :after ((this base) &key)
> >   (format t "Initializing base ~a~%" this)
> >   (setf (storage this) (make-array (+ (dim this)
> >                                  (padding this))
> >                               :initial-element 0d0)))
>
> > (defclass sub1a (base)
> >   ((dummy
> >     :initform 2d0
> >     :accessor dummy))
> >  (:documentation "This will implement a higher order interpolations
> > that needs padding")
>
> > ;; I would like to modify padding here.
> > (defmethod initialize-instance :after ((this sub1a) &key)
> >   (format t "Initializing sub ~a~%" this)
> >   (setf (padding this) 2))
>
> > To get what I want, I need to do
>
> >>(make-instance 'sub1a :padding 2)
>
> > but I would prefer to do just
>
> >>(make-instance 'sub1a)
>
> > This, of course does not work, ...
>
> I wish you had proved that with repl output...oh, christ, you are not
> talking about padding, you are talking about the storage. Which takes me
> back to your use of "This" which in turn takes me back to high school
> geometry and Mr. Wiseman who always said "There's no room for pronouns
> in geometry, Mr. Tilton.
>
> > because first the base's initialize-
> > instance method is called, which sort-of makes sense.
>
> That One will be along shortly to recommend either a metaclass or
> AspectL, I will recommend Cells which always does things In the Right
> Order(tm). And happily saves you from having to write i-i methods, that
> name is too long and I have carpal tunnel, dammit! I digress.
>
> A humbler "gee, let's do everything with CLOS!" solution would be to use
> an :around method to set up the storage slot, doing so /after/
> call-next-method to get the desired effect.
>
> But now we have the CLOS tail wagging the dog, which I am afraid is you.
>   What happens when things get more complicated and you run out of
> stupid GF dispatch tricks? /Now/ we need That One. Or Cells.
>
> Interestingly, Cells was invented precisely to solve a problem with
> order of calculation -- one where slots needed the value of slots from
> other instances as well as the same -- not to do reactive programming
> (the handiest name for this particular pet trick). Reactive just fell
> out of the tree, which was the second sign to me that Cells was way
> cool. The first was how it trivially dispatched the daunting problem of
> getting complex gui geometry calculated in the right order.

Hmm.  I will not change the code for now, but I'll keep it in mind.
>
>
>
> > The first approach looks kind of kludgy, even though Keene (yep, I
> > went to the library and got the CLOS book) suggests using constructors
> > to hide the ugly make-instance details.
>
> She was simply wrong. That breaks the usefulness of generic dispatch.
>
>
>
> > In real world, the base class is a an "abstract/virtual" (not sure of
> > the difference) class for a differential equation solver, while the
> > (layered) subclasses are particular instances of the solvers, some of
> > which build on top of others.  The base class provides the basic
> > storage, and methods for storing, accessing, and numerical
> > computations.
>
> Do I tell you my problems? :)

Well, sometimes (if by you, you mean plural).  I was just trying to
provide the context for the problem.

>
> hth,kzo

It does, always :-)

Thanks
From: Kenny
Subject: Re: Can sub-classes initialize-instance modify base-classes slot  *before* base's initialize-instance executes?
Date: 
Message-ID: <48eee2e6$0$4907$607ed4bc@cv.net>
·············@gmail.com wrote:
> On Oct 9, 4:05 pm, Kenny <·········@gmail.com> wrote:
> 
>>·············@gmail.com wrote:
>>
>>>I suspect the answer is no, and in which case I will revisit my
>>>concept.  But here is the story.
>>
>>>I have a base class that initializes storage.  One of its subclasses
>>>needs extra padding around the storage.  The base classes initializes
>>>the padding to zero, and the subclasses ought to change that.  Is
>>>there some way to specify this within the standard CLOS machinery?
>>
>>>Here is the example code:
>>
>>>(in-package :cl-user)
>>
>>>(defclass base ()
>>>  ((dim
>>>    :initform 12
>>>    :accessor dim)
>>>   (padding
>>>    :initform 0
>>>    :accessor padding
>>>    :initarg :padding
>>>    :documentation "Padding is necessary for some higher order
>>>interpolations")
>>>   (storage
>>>    :initform nil
>>>    :accessor storage)))
>>>(defmethod initialize-instance :after ((this base) &key)
>>>  (format t "Initializing base ~a~%" this)
>>>  (setf (storage this) (make-array (+ (dim this)
>>>                                 (padding this))
>>>                              :initial-element 0d0)))
>>
>>>(defclass sub1a (base)
>>>  ((dummy
>>>    :initform 2d0
>>>    :accessor dummy))
>>> (:documentation "This will implement a higher order interpolations
>>>that needs padding")
>>
>>>;; I would like to modify padding here.
>>>(defmethod initialize-instance :after ((this sub1a) &key)
>>>  (format t "Initializing sub ~a~%" this)
>>>  (setf (padding this) 2))
>>
>>>To get what I want, I need to do
>>
>>>>(make-instance 'sub1a :padding 2)
>>
>>>but I would prefer to do just
>>
>>>>(make-instance 'sub1a)
>>
>>>This, of course does not work, ...
>>
>>I wish you had proved that with repl output...oh, christ, you are not
>>talking about padding, you are talking about the storage. Which takes me
>>back to your use of "This" which in turn takes me back to high school
>>geometry and Mr. Wiseman who always said "There's no room for pronouns
>>in geometry, Mr. Tilton.
>>
>>
>>>because first the base's initialize-
>>>instance method is called, which sort-of makes sense.
>>
>>That One will be along shortly to recommend either a metaclass or
>>AspectL, I will recommend Cells which always does things In the Right
>>Order(tm). And happily saves you from having to write i-i methods, that
>>name is too long and I have carpal tunnel, dammit! I digress.
>>
>>A humbler "gee, let's do everything with CLOS!" solution would be to use
>>an :around method to set up the storage slot, doing so /after/
>>call-next-method to get the desired effect.
>>
>>But now we have the CLOS tail wagging the dog, which I am afraid is you.
>>  What happens when things get more complicated and you run out of
>>stupid GF dispatch tricks? /Now/ we need That One. Or Cells.
>>
>>Interestingly, Cells was invented precisely to solve a problem with
>>order of calculation -- one where slots needed the value of slots from
>>other instances as well as the same -- not to do reactive programming
>>(the handiest name for this particular pet trick). Reactive just fell
>>out of the tree, which was the second sign to me that Cells was way
>>cool. The first was how it trivially dispatched the daunting problem of
>>getting complex gui geometry calculated in the right order.
> 
> 
> Hmm.  I will not change the code for now, but I'll keep it in mind.

OK, great, and I will keep in mind daily exercise and reducing my drug 
dependencies. Because neither of us wants to do it. I don't want to drag 
my ass out of bed every morning and run up and down the frickin 
boardwalk and/or give up my drugs of choice and you and Costanza and 
Seibel and 90 out of 96 yobbos are not as cool as you think you are when 
it comes to being clued into hot technology and if you were honest would 
say you are scared to death of learning anything new.

You drape yourselves in Lisp and prance about as if you are special when 
you are not. Lisp is special. You are just average drones who have 
wandered by mistake into this hallowed space and think it makes you 
cool. It does not.

What would make you cool is an openness to good ideas. That One(tm) 
mocked me for openness recently sealing his fate like Pete Rose. 
Meanwhile, why is JMcC a genius aka clearly an alien? He sailed straight 
past CPUs and instruction sets to this whacky idea that code should be 
data. WTF? OK, he was helped by the RFE (reality) which requires that 
code be data but he still gets more points than I ever will for noticing.

The good news is that you have your hands clapped over your ears and are 
going Wooo! Wooo! Wooo! The bad news is it should have been your eyes.

>>hth,kzo
> 
> 
> It does, always :-)

No it doesn't unless you are subscribed to cells-devel and I did not 
notice. Or clozure-cells or open-laszlo or adobe adam or father time or 
I really do not care... game over?  The yobbos sob openly and fall on 
their swords: Kenny told them, and they mocked him, because he made fun 
of McCLIM, one of their pet projects, violating the Code of the Pig.

Meanwhile the entire frickin world of programming moves on to automatic 
state management, an order of magnitude more important than automatic 
memory management.

As for Lispers...there is no such thing: using Lisp does not make you a 
Lisper. Lisp is a state of mind. If you do not enjoy the state of 
mind...talk about a self-finishing sentence!

k.x.o
From: ·············@gmail.com
Subject: Re: Can sub-classes initialize-instance modify base-classes slot 	*before* base's initialize-instance executes?
Date: 
Message-ID: <453d7313-b0d5-41de-a381-8a7c49e250c4@n1g2000prb.googlegroups.com>
On Oct 10, 1:06 am, Kenny <·········@gmail.com> wrote:
> ·············@gmail.com wrote:
> > On Oct 9, 4:05 pm, Kenny <·········@gmail.com> wrote:
>
> >>·············@gmail.com wrote:
>
> >>>I suspect the answer is no, and in which case I will revisit my
> >>>concept.  But here is the story.
>
> >>>I have a base class that initializes storage.  One of its subclasses
> >>>needs extra padding around the storage.  The base classes initializes
> >>>the padding to zero, and the subclasses ought to change that.  Is
> >>>there some way to specify this within the standard CLOS machinery?
>
> >>>Here is the example code:
>
> >>>(in-package :cl-user)
>
> >>>(defclass base ()
> >>>  ((dim
> >>>    :initform 12
> >>>    :accessor dim)
> >>>   (padding
> >>>    :initform 0
> >>>    :accessor padding
> >>>    :initarg :padding
> >>>    :documentation "Padding is necessary for some higher order
> >>>interpolations")
> >>>   (storage
> >>>    :initform nil
> >>>    :accessor storage)))
> >>>(defmethod initialize-instance :after ((this base) &key)
> >>>  (format t "Initializing base ~a~%" this)
> >>>  (setf (storage this) (make-array (+ (dim this)
> >>>                                 (padding this))
> >>>                              :initial-element 0d0)))
>
> >>>(defclass sub1a (base)
> >>>  ((dummy
> >>>    :initform 2d0
> >>>    :accessor dummy))
> >>> (:documentation "This will implement a higher order interpolations
> >>>that needs padding")
>
> >>>;; I would like to modify padding here.
> >>>(defmethod initialize-instance :after ((this sub1a) &key)
> >>>  (format t "Initializing sub ~a~%" this)
> >>>  (setf (padding this) 2))
>
> >>>To get what I want, I need to do
>
> >>>>(make-instance 'sub1a :padding 2)
>
> >>>but I would prefer to do just
>
> >>>>(make-instance 'sub1a)
>
> >>>This, of course does not work, ...
>
> >>I wish you had proved that with repl output...oh, christ, you are not
> >>talking about padding, you are talking about the storage. Which takes me
> >>back to your use of "This" which in turn takes me back to high school
> >>geometry and Mr. Wiseman who always said "There's no room for pronouns
> >>in geometry, Mr. Tilton.
>
> >>>because first the base's initialize-
> >>>instance method is called, which sort-of makes sense.
>
> >>That One will be along shortly to recommend either a metaclass or
> >>AspectL, I will recommend Cells which always does things In the Right
> >>Order(tm). And happily saves you from having to write i-i methods, that
> >>name is too long and I have carpal tunnel, dammit! I digress.
>
> >>A humbler "gee, let's do everything with CLOS!" solution would be to use
> >>an :around method to set up the storage slot, doing so /after/
> >>call-next-method to get the desired effect.
>
> >>But now we have the CLOS tail wagging the dog, which I am afraid is you.
> >>  What happens when things get more complicated and you run out of
> >>stupid GF dispatch tricks? /Now/ we need That One. Or Cells.
>
> >>Interestingly, Cells was invented precisely to solve a problem with
> >>order of calculation -- one where slots needed the value of slots from
> >>other instances as well as the same -- not to do reactive programming
> >>(the handiest name for this particular pet trick). Reactive just fell
> >>out of the tree, which was the second sign to me that Cells was way
> >>cool. The first was how it trivially dispatched the daunting problem of
> >>getting complex gui geometry calculated in the right order.
>
> > Hmm.  I will not change the code for now, but I'll keep it in mind.
>
> OK, great, and I will keep in mind daily exercise and reducing my drug
> dependencies. Because neither of us wants to do it. I don't want to drag
> my ass out of bed every morning and run up and down the frickin
> boardwalk and/or give up my drugs of choice and you and Costanza and
> Seibel and 90 out of 96 yobbos are not as cool as you think you are when
> it comes to being clued into hot technology and if you were honest would
> say you are scared to death of learning anything new.
>
> You drape yourselves in Lisp and prance about as if you are special when
> you are not. Lisp is special. You are just average drones who have
> wandered by mistake into this hallowed space and think it makes you
> cool. It does not.
>
> What would make you cool is an openness to good ideas. That One(tm)
> mocked me for openness recently sealing his fate like Pete Rose.
> Meanwhile, why is JMcC a genius aka clearly an alien? He sailed straight
> past CPUs and instruction sets to this whacky idea that code should be
> data. WTF? OK, he was helped by the RFE (reality) which requires that
> code be data but he still gets more points than I ever will for noticing.
>
> The good news is that you have your hands clapped over your ears and are
> going Wooo! Wooo! Wooo! The bad news is it should have been your eyes.
>
> >>hth,kzo
>
> > It does, always :-)
>
> No it doesn't unless you are subscribed to cells-devel and I did not
> notice. Or clozure-cells or open-laszlo or adobe adam or father time or
> I really do not care... game over?  The yobbos sob openly and fall on
> their swords: Kenny told them, and they mocked him, because he made fun
> of McCLIM, one of their pet projects, violating the Code of the Pig.

Dude, I am not some young wily and agile uber-programmer that changes
on the spot :-)  Just muddling my way through, watching & learning
ever so sloowly from you great wizards.  I can learn one thing at
after trying it several times.


>
> Meanwhile the entire frickin world of programming moves on to automatic
> state management, an order of magnitude more important than automatic
> memory management.
>
> As for Lispers...there is no such thing: using Lisp does not make you a
> Lisper. Lisp is a state of mind. If you do not enjoy the state of
> mind...talk about a self-finishing sentence!
>
> k.x.o
From: Frank GOENNINGER
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <lzskr4r9h5.fsf@goenninger.net>
Kenny <·········@gmail.com> writes:

> ·············@gmail.com wrote:
>> On Oct 9, 4:05 pm, Kenny <·········@gmail.com> wrote:
>>
>>>·············@gmail.com wrote:
>>>
>>>>I suspect the answer is no, and in which case I will revisit my
>>>>concept.  But here is the story.
>>>
>>>>I have a base class that initializes storage.  One of its subclasses
>>>>needs extra padding around the storage.  The base classes initializes
>>>>the padding to zero, and the subclasses ought to change that.  Is
>>>>there some way to specify this within the standard CLOS machinery?
>>>
>>>>Here is the example code:
>>>
>>>>(in-package :cl-user)
>>>
>>>>(defclass base ()
>>>>  ((dim
>>>>    :initform 12
>>>>    :accessor dim)
>>>>   (padding
>>>>    :initform 0
>>>>    :accessor padding
>>>>    :initarg :padding
>>>>    :documentation "Padding is necessary for some higher order
>>>>interpolations")
>>>>   (storage
>>>>    :initform nil
>>>>    :accessor storage)))
>>>>(defmethod initialize-instance :after ((this base) &key)
>>>>  (format t "Initializing base ~a~%" this)
>>>>  (setf (storage this) (make-array (+ (dim this)
>>>>                                 (padding this))
>>>>                              :initial-element 0d0)))
>>>
>>>>(defclass sub1a (base)
>>>>  ((dummy
>>>>    :initform 2d0
>>>>    :accessor dummy))
>>>> (:documentation "This will implement a higher order interpolations
>>>>that needs padding")
>>>
>>>>;; I would like to modify padding here.
>>>>(defmethod initialize-instance :after ((this sub1a) &key)
>>>>  (format t "Initializing sub ~a~%" this)
>>>>  (setf (padding this) 2))
>>>
>>>>To get what I want, I need to do
>>>
>>>>>(make-instance 'sub1a :padding 2)
>>>
>>>>but I would prefer to do just
>>>
>>>>>(make-instance 'sub1a)
>>>
>>>>This, of course does not work, ...
>>>
>>>I wish you had proved that with repl output...oh, christ, you are not
>>>talking about padding, you are talking about the storage. Which takes me
>>>back to your use of "This" which in turn takes me back to high school
>>>geometry and Mr. Wiseman who always said "There's no room for pronouns
>>>in geometry, Mr. Tilton.
>>>
>>>
>>>>because first the base's initialize-
>>>>instance method is called, which sort-of makes sense.
>>>
>>>That One will be along shortly to recommend either a metaclass or
>>>AspectL, I will recommend Cells which always does things In the Right
>>>Order(tm). And happily saves you from having to write i-i methods, that
>>>name is too long and I have carpal tunnel, dammit! I digress.
>>>
>>>A humbler "gee, let's do everything with CLOS!" solution would be to use
>>>an :around method to set up the storage slot, doing so /after/
>>>call-next-method to get the desired effect.
>>>
>>>But now we have the CLOS tail wagging the dog, which I am afraid is you.
>>>  What happens when things get more complicated and you run out of
>>>stupid GF dispatch tricks? /Now/ we need That One. Or Cells.
>>>
>>>Interestingly, Cells was invented precisely to solve a problem with
>>>order of calculation -- one where slots needed the value of slots from
>>>other instances as well as the same -- not to do reactive programming
>>>(the handiest name for this particular pet trick). Reactive just fell
>>>out of the tree, which was the second sign to me that Cells was way
>>>cool. The first was how it trivially dispatched the daunting problem of
>>>getting complex gui geometry calculated in the right order.
>>
>>
>> Hmm.  I will not change the code for now, but I'll keep it in mind.
>
> OK, great, and I will keep in mind daily exercise and reducing my drug
> dependencies. Because neither of us wants to do it. I don't want to
> drag my ass out of bed every morning and run up and down the frickin
> boardwalk and/or give up my drugs of choice and you and Costanza and
> Seibel and 90 out of 96 yobbos are not as cool as you think you are
> when it comes to being clued into hot technology and if you were
> honest would say you are scared to death of learning anything new.
>
> You drape yourselves in Lisp and prance about as if you are special
> when you are not. Lisp is special. You are just average drones who
> have wandered by mistake into this hallowed space and think it makes
> you cool. It does not.
>
> What would make you cool is an openness to good ideas. That One(tm)
> mocked me for openness recently sealing his fate like Pete
> Rose. Meanwhile, why is JMcC a genius aka clearly an alien? He sailed
> straight past CPUs and instruction sets to this whacky idea that code
> should be data. WTF? OK, he was helped by the RFE (reality) which
> requires that code be data but he still gets more points than I ever
> will for noticing.
>
> The good news is that you have your hands clapped over your ears and
> are going Wooo! Wooo! Wooo! The bad news is it should have been your
> eyes.
>
>>>hth,kzo
>>
>>
>> It does, always :-)
>
> No it doesn't unless you are subscribed to cells-devel and I did not
> notice. Or clozure-cells or open-laszlo or adobe adam or father time
> or I really do not care... game over?  The yobbos sob openly and fall
> on their swords: Kenny told them, and they mocked him, because he made
> fun of McCLIM, one of their pet projects, violating the Code of the
> Pig.
>
> Meanwhile the entire frickin world of programming moves on to
> automatic state management, an order of magnitude more important than
> automatic memory management.
>
> As for Lispers...there is no such thing: using Lisp does not make you
> a Lisper. Lisp is a state of mind. If you do not enjoy the state of
> mind...talk about a self-finishing sentence!
>
> k.x.o
>

(in-package :cells)

(defmd base ()
  (dim (c-in 12))
  (padding (c-in 0)))

(defmd sub1a (base)
  (dummy (c-in 2d0))
  :padding (c-in 2))

(defun test-it ()
  (describe (make-instance 'sub1a)))

CELLS> (test-it)
SUB1A0 is an instance of #<STANDARD-CLASS SUB1A>:
 The following slots have :INSTANCE allocation:
  .MD-STATE           :AWAKE
  .AWAKEN-ON-INIT-P   NIL
  .CELLS              ((DUMMY . <0:A DUMMY/SUB1A0 = 2.0d0>)
                       (PADDING . <0:A PADDING/SUB1A0 = 2>)
                       (DIM . <0:A DIM/SUB1A0 = 12>))
  .CELLS-FLUSHED      NIL
  ADOPT-CT            0
  .MD-NAME            SUB1A0
  .FM-PARENT          NIL
  .VALUE              NIL
  ZDBG                NIL
  DIM                 12
  PADDING             2
  DUMMY               2.0d0

;-)  

Productivity? Yes, that's what I care about.

Cheers!
   Frank

-- 
  frgo(at)me(dot)com

  "Don't ask me! I haven't been reading comp.lang.lisp long enough to 
  really know ..."
From: Kenny
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <48ef4d3c$0$4978$607ed4bc@cv.net>
Frank GOENNINGER wrote:
> Kenny <·········@gmail.com> writes:
> 
> 
>>·············@gmail.com wrote:
>>
>>>On Oct 9, 4:05 pm, Kenny <·········@gmail.com> wrote:
>>>
>>>
>>>>·············@gmail.com wrote:
>>>>
>>>>
>>>>>I suspect the answer is no, and in which case I will revisit my
>>>>>concept.  But here is the story.
>>>>
>>>>>I have a base class that initializes storage.  One of its subclasses
>>>>>needs extra padding around the storage.  The base classes initializes
>>>>>the padding to zero, and the subclasses ought to change that.  Is
>>>>>there some way to specify this within the standard CLOS machinery?
>>>>
>>>>>Here is the example code:
>>>>
>>>>>(in-package :cl-user)
>>>>
>>>>>(defclass base ()
>>>>> ((dim
>>>>>   :initform 12
>>>>>   :accessor dim)
>>>>>  (padding
>>>>>   :initform 0
>>>>>   :accessor padding
>>>>>   :initarg :padding
>>>>>   :documentation "Padding is necessary for some higher order
>>>>>interpolations")
>>>>>  (storage
>>>>>   :initform nil
>>>>>   :accessor storage)))
>>>>>(defmethod initialize-instance :after ((this base) &key)
>>>>> (format t "Initializing base ~a~%" this)
>>>>> (setf (storage this) (make-array (+ (dim this)
>>>>>                                (padding this))
>>>>>                             :initial-element 0d0)))
>>>>
>>>>>(defclass sub1a (base)
>>>>> ((dummy
>>>>>   :initform 2d0
>>>>>   :accessor dummy))
>>>>>(:documentation "This will implement a higher order interpolations
>>>>>that needs padding")
>>>>
>>>>>;; I would like to modify padding here.
>>>>>(defmethod initialize-instance :after ((this sub1a) &key)
>>>>> (format t "Initializing sub ~a~%" this)
>>>>> (setf (padding this) 2))
>>>>
>>>>>To get what I want, I need to do
>>>>
>>>>>>(make-instance 'sub1a :padding 2)
>>>>
>>>>>but I would prefer to do just
>>>>
>>>>>>(make-instance 'sub1a)
>>>>
>>>>>This, of course does not work, ...
>>>>
>>>>I wish you had proved that with repl output...oh, christ, you are not
>>>>talking about padding, you are talking about the storage. Which takes me
>>>>back to your use of "This" which in turn takes me back to high school
>>>>geometry and Mr. Wiseman who always said "There's no room for pronouns
>>>>in geometry, Mr. Tilton.
>>>>
>>>>
>>>>
>>>>>because first the base's initialize-
>>>>>instance method is called, which sort-of makes sense.
>>>>
>>>>That One will be along shortly to recommend either a metaclass or
>>>>AspectL, I will recommend Cells which always does things In the Right
>>>>Order(tm). And happily saves you from having to write i-i methods, that
>>>>name is too long and I have carpal tunnel, dammit! I digress.
>>>>
>>>>A humbler "gee, let's do everything with CLOS!" solution would be to use
>>>>an :around method to set up the storage slot, doing so /after/
>>>>call-next-method to get the desired effect.
>>>>
>>>>But now we have the CLOS tail wagging the dog, which I am afraid is you.
>>>> What happens when things get more complicated and you run out of
>>>>stupid GF dispatch tricks? /Now/ we need That One. Or Cells.
>>>>
>>>>Interestingly, Cells was invented precisely to solve a problem with
>>>>order of calculation -- one where slots needed the value of slots from
>>>>other instances as well as the same -- not to do reactive programming
>>>>(the handiest name for this particular pet trick). Reactive just fell
>>>>out of the tree, which was the second sign to me that Cells was way
>>>>cool. The first was how it trivially dispatched the daunting problem of
>>>>getting complex gui geometry calculated in the right order.
>>>
>>>
>>>Hmm.  I will not change the code for now, but I'll keep it in mind.
>>
>>OK, great, and I will keep in mind daily exercise and reducing my drug
>>dependencies. Because neither of us wants to do it. I don't want to
>>drag my ass out of bed every morning and run up and down the frickin
>>boardwalk and/or give up my drugs of choice and you and Costanza and
>>Seibel and 90 out of 96 yobbos are not as cool as you think you are
>>when it comes to being clued into hot technology and if you were
>>honest would say you are scared to death of learning anything new.
>>
>>You drape yourselves in Lisp and prance about as if you are special
>>when you are not. Lisp is special. You are just average drones who
>>have wandered by mistake into this hallowed space and think it makes
>>you cool. It does not.
>>
>>What would make you cool is an openness to good ideas. That One(tm)
>>mocked me for openness recently sealing his fate like Pete
>>Rose. Meanwhile, why is JMcC a genius aka clearly an alien? He sailed
>>straight past CPUs and instruction sets to this whacky idea that code
>>should be data. WTF? OK, he was helped by the RFE (reality) which
>>requires that code be data but he still gets more points than I ever
>>will for noticing.
>>
>>The good news is that you have your hands clapped over your ears and
>>are going Wooo! Wooo! Wooo! The bad news is it should have been your
>>eyes.
>>
>>
>>>>hth,kzo
>>>
>>>
>>>It does, always :-)
>>
>>No it doesn't unless you are subscribed to cells-devel and I did not
>>notice. Or clozure-cells or open-laszlo or adobe adam or father time
>>or I really do not care... game over?  The yobbos sob openly and fall
>>on their swords: Kenny told them, and they mocked him, because he made
>>fun of McCLIM, one of their pet projects, violating the Code of the
>>Pig.
>>
>>Meanwhile the entire frickin world of programming moves on to
>>automatic state management, an order of magnitude more important than
>>automatic memory management.
>>
>>As for Lispers...there is no such thing: using Lisp does not make you
>>a Lisper. Lisp is a state of mind. If you do not enjoy the state of
>>mind...talk about a self-finishing sentence!
>>
>>k.x.o
>>
> 
> 
> (in-package :cells)
> 
> (defmd base ()
Don't forget the punch line:
     (storage (c? (make-array (+ (^dim)(^padding))
                   :initial-element (^dummy))))
>   (dim (c-in 12))
>   (padding (c-in 0)))
> 
> (defmd sub1a (base)
>   (dummy (c-in 2d0))
>   :padding (c-in 2))
> 
> (defun test-it ()
>   (describe (make-instance 'sub1a
                 :dummy (c? (/ (^dim) 3d0)))))
> 
> CELLS> (test-it)
> SUB1A0 is an instance of #<STANDARD-CLASS SUB1A>:
>  The following slots have :INSTANCE allocation:
>   .MD-STATE           :AWAKE
>   .AWAKEN-ON-INIT-P   NIL
>   .CELLS              ((DUMMY . <0:A DUMMY/SUB1A0 = 2.0d0>)
>                        (PADDING . <0:A PADDING/SUB1A0 = 2>)
>                        (DIM . <0:A DIM/SUB1A0 = 12>))
>   .CELLS-FLUSHED      NIL
>   ADOPT-CT            0
>   .MD-NAME            SUB1A0
>   .FM-PARENT          NIL
>   .VALUE              NIL
>   ZDBG                NIL
     STORAGE             #(4.0d0 4.0d0 4.0d0 4.0d0 ...)
>   DIM                 12
>   PADDING             2
>   DUMMY               2.0d0
> 
> ;-)  

:)

kt
From: George Neuner
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <v3eve4pcb5mussmprnm478jl23bgjeslbc@4ax.com>
On Fri, 10 Oct 2008 01:06:22 -0400, Kenny <·········@gmail.com> wrote:


>OK, great, and I will keep in mind daily exercise and reducing my drug 
>dependencies. Because neither of us wants to do it. I don't want to drag 
>my ass out of bed every morning and run up and down the frickin 
>boardwalk and/or give up my drugs of choice and you and Costanza and 
>Seibel and 90 out of 96 yobbos are not as cool as you think you are when 
>it comes to being clued into hot technology and if you were honest would 
>say you are scared to death of learning anything new.
>
>You drape yourselves in Lisp and prance about as if you are special when 
>you are not. Lisp is special. You are just average drones who have 
>wandered by mistake into this hallowed space and think it makes you 
>cool. It does not.
>
>What would make you cool is an openness to good ideas. That One(tm) 
>mocked me for openness recently sealing his fate like Pete Rose. 
>Meanwhile, why is JMcC a genius aka clearly an alien? He sailed straight 
>past CPUs and instruction sets to this whacky idea that code should be 
>data. WTF? OK, he was helped by the RFE (reality) which requires that 
>code be data but he still gets more points than I ever will for noticing.
>
>The good news is that you have your hands clapped over your ears and are 
>going Wooo! Wooo! Wooo! The bad news is it should have been your eyes.

I think it's time for Kenny's nap.

George
From: Kenny
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <48eff1b3$0$4967$607ed4bc@cv.net>
George Neuner wrote:
> On Fri, 10 Oct 2008 01:06:22 -0400, Kenny <·········@gmail.com> wrote:
>>The good news is that you have your hands clapped over your ears and are 
>>going Wooo! Wooo! Wooo! The bad news is it should have been your eyes.
> 
> 
> I think it's time for Kenny's nap.

I think George does not know anything about Cells. Or Adam. Or Father 
Time. Or OpenLaszlo. Hell, not even KR?

<sigh>

What can I say to help? Cells cells cells cells cells?

:)

hth, kenny
From: André Thieme
Subject: Re: Can sub-classes initialize-instance modify base-classes slot  *before* base's initialize-instance executes?
Date: 
Message-ID: <gcp9jh$pv9$1@registered.motzarella.org>
Make a very cool looking website, full with Ajax and stuff.
Give a detailed manual and some how-to�s.
Publish some videos at youtube that show how cool Cells are.
So, basically do what they did for Rails (Ruby) with Cells for Lisp
and thousands of Lispers will use Cells next year.


Andr�
-- 
From: Kenny
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <48f03737$0$4965$607ed4bc@cv.net>
Andr� Thieme wrote:
> Make a very cool looking website, full with Ajax and stuff.
> Give a detailed manual and some how-to�s.
> Publish some videos at youtube that show how cool Cells are.
> So, basically do what they did for Rails (Ruby) with Cells for Lisp
> and thousands of Lispers will use Cells next year.

Sounds like work. And terribly un-Lispy: we welcome noobs with Emacs and 
Slime and pretend it is an ISE.

Besides, if they were Lispers they would not need to be tricked into 
discovering Cells, they just would. Enough have that I know enough not 
to bother with those who have not.  I'd like to see an AI tool parse 
that sentence without killing the crew. I digress.

George Neuner recently posted brilliantly on the difference between 
using Lisp and truly enjoying Lisp Mind (tm). Check it out.

best,kzo
From: Rainer Joswig
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <joswig-624390.20244209102008@news-europe.giganews.com>
In article 
<····································@b2g2000prf.googlegroups.com>,
 ·············@gmail.com wrote:

> I suspect the answer is no, and in which case I will revisit my
> concept.  But here is the story.
> 
> I have a base class that initializes storage.  One of its subclasses
> needs extra padding around the storage.  The base classes initializes
> the padding to zero, and the subclasses ought to change that.  Is
> there some way to specify this within the standard CLOS machinery?
> 
> Here is the example code:
> 
> (in-package :cl-user)
> 
> (defclass base ()
>   ((dim
>     :initform 12
>     :accessor dim)
>    (padding
>     :initform 0
>     :accessor padding
>     :initarg :padding
>     :documentation "Padding is necessary for some higher order
> interpolations")
>    (storage
>     :initform nil
>     :accessor storage)))
> (defmethod initialize-instance :after ((this base) &key)
>   (format t "Initializing base ~a~%" this)
>   (setf (storage this) (make-array (+ (dim this)
> 				      (padding this))
> 				   :initial-element 0d0)))
> 
> (defclass sub1a (base)
>   ((dummy
>     :initform 2d0
>     :accessor dummy))
>  (:documentation "This will implement a higher order interpolations
> that needs padding")
> 
> ;; I would like to modify padding here.
> (defmethod initialize-instance :after ((this sub1a) &key)
>   (format t "Initializing sub ~a~%" this)
>   (setf (padding this) 2))

Sure. Why not. Remember that all :after methods are running.

CL-USER 26 > (defclass c1 () (a))
#<STANDARD-CLASS C1 200AFF37>

CL-USER 27 > (defclass c2 (c1) ())
#<STANDARD-CLASS C2 200AE0B7>

CL-USER 28 > (defmethod initialize-instance :after ((object c1) &key) (setf (slot-value object 'a) 'c1-value))
#<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C1) 200964C3>

CL-USER 29 > (defmethod initialize-instance :after ((object c2) &key) (setf (slot-value object 'a) 'c2-value))
#<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C2) 21E2D45F>

CL-USER 30 > (describe (make-instance 'c2))

#<C2 21A36597> is a C2
A      C2-VALUE


The slot is set twice. first to c1-value and then to c2-value.
First the :after method for C1 is running, then the :after method
for C2.

> 
> 
> To get what I want, I need to do
> > (make-instance 'sub1a :padding 2)
> but I would prefer to do just
> > (make-instance 'sub1a)
> This, of course does not work, because first the base's initialize-
> instance method is called, which sort-of makes sense.

But then the :after methods are running. The :after methods
from the subclass is running later.

Similar, all the :before methods are running. The :before
methods from the subclasses are running first:

For a method like initialize-instance with an object of class C2:

  :after c2
     :after c1
       primary c2 -> call-next-method -> primary c1
     :before c1
  :after c2

The value of the primary method for c2 is returned as the value
for the generic function call.      

(there are also :around methods)

> 
> The first approach looks kind of kludgy, even though Keene (yep, I
> went to the library and got the CLOS book) suggests using constructors
> to hide the ugly make-instance details.
> 
> In real world, the base class is a an "abstract/virtual" (not sure of
> the difference) class for a differential equation solver, while the
> (layered) subclasses are particular instances of the solvers, some of
> which build on top of others.  The base class provides the basic
> storage, and methods for storing, accessing, and numerical
> computations.

Also remember this:

CL-USER 33 > (defclass ce1 ()
               ((a :initform 'ce1-value)))
#<STANDARD-CLASS CE1 2009B607>

CL-USER 34 > (describe (make-instance 'ce1))

#<CE1 20099607> is a CE1
A      CE1-VALUE

CL-USER 35 > (defclass ce2 ()
               ((a :initform 'ce2-value)))
#<STANDARD-CLASS CE2 200A60D7>

CL-USER 36 > (describe (make-instance 'ce2))

#<CE2 200DEB8F> is a CE2
A      CE2-VALUE

Slots with the same name are merged. CE2 has only
one slot named A. The initform for CE2 will be used
when you make an instance of CE2.

> 
> Thanks,
> 
> Mirko

-- 
http://lispm.dyndns.org/
From: ·············@gmail.com
Subject: Re: Can sub-classes initialize-instance modify base-classes slot 	*before* base's initialize-instance executes?
Date: 
Message-ID: <8036ed5d-d6df-4440-b230-993712326cc9@75g2000hso.googlegroups.com>
On Oct 9, 2:25 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@b2g2000prf.googlegroups.com>,
>
>
>
>  ·············@gmail.com wrote:
> > I suspect the answer is no, and in which case I will revisit my
> > concept.  But here is the story.
>
> > I have a base class that initializes storage.  One of its subclasses
> > needs extra padding around the storage.  The base classes initializes
> > the padding to zero, and the subclasses ought to change that.  Is
> > there some way to specify this within the standard CLOS machinery?
>
> > Here is the example code:
>
> > (in-package :cl-user)
>
> > (defclass base ()
> >   ((dim
> >     :initform 12
> >     :accessor dim)
> >    (padding
> >     :initform 0
> >     :accessor padding
> >     :initarg :padding
> >     :documentation "Padding is necessary for some higher order
> > interpolations")
> >    (storage
> >     :initform nil
> >     :accessor storage)))
> > (defmethod initialize-instance :after ((this base) &key)
> >   (format t "Initializing base ~a~%" this)
> >   (setf (storage this) (make-array (+ (dim this)
> >                                  (padding this))
> >                               :initial-element 0d0)))
>
> > (defclass sub1a (base)
> >   ((dummy
> >     :initform 2d0
> >     :accessor dummy))
> >  (:documentation "This will implement a higher order interpolations
> > that needs padding")
>
> > ;; I would like to modify padding here.
> > (defmethod initialize-instance :after ((this sub1a) &key)
> >   (format t "Initializing sub ~a~%" this)
> >   (setf (padding this) 2))
>
> Sure. Why not. Remember that all :after methods are running.
>
> CL-USER 26 > (defclass c1 () (a))
> #<STANDARD-CLASS C1 200AFF37>
>
> CL-USER 27 > (defclass c2 (c1) ())
> #<STANDARD-CLASS C2 200AE0B7>
>
> CL-USER 28 > (defmethod initialize-instance :after ((object c1) &key) (setf (slot-value object 'a) 'c1-value))
> #<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C1) 200964C3>
>
> CL-USER 29 > (defmethod initialize-instance :after ((object c2) &key) (setf (slot-value object 'a) 'c2-value))
> #<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C2) 21E2D45F>
>
> CL-USER 30 > (describe (make-instance 'c2))
>
> #<C2 21A36597> is a C2
> A      C2-VALUE
>
> The slot is set twice. first to c1-value and then to c2-value.
> First the :after method for C1 is running, then the :after method
> for C2.
>
>
>
> > To get what I want, I need to do
> > > (make-instance 'sub1a :padding 2)
> > but I would prefer to do just
> > > (make-instance 'sub1a)
> > This, of course does not work, because first the base's initialize-
> > instance method is called, which sort-of makes sense.
>
> But then the :after methods are running. The :after methods
> from the subclass is running later.
>
> Similar, all the :before methods are running. The :before
> methods from the subclasses are running first:
>
> For a method like initialize-instance with an object of class C2:
>
>   :after c2
>      :after c1
>        primary c2 -> call-next-method -> primary c1
>      :before c1
>   :after c2
>
> The value of the primary method for c2 is returned as the value
> for the generic function call.      
>
> (there are also :around methods)
>
>
>
> > The first approach looks kind of kludgy, even though Keene (yep, I
> > went to the library and got the CLOS book) suggests using constructors
> > to hide the ugly make-instance details.
>
> > In real world, the base class is a an "abstract/virtual" (not sure of
> > the difference) class for a differential equation solver, while the
> > (layered) subclasses are particular instances of the solvers, some of
> > which build on top of others.  The base class provides the basic
> > storage, and methods for storing, accessing, and numerical
> > computations.
>
> Also remember this:
>
> CL-USER 33 > (defclass ce1 ()
>                ((a :initform 'ce1-value)))
> #<STANDARD-CLASS CE1 2009B607>
>
> CL-USER 34 > (describe (make-instance 'ce1))
>
> #<CE1 20099607> is a CE1
> A      CE1-VALUE
>
> CL-USER 35 > (defclass ce2 ()
>                ((a :initform 'ce2-value)))
> #<STANDARD-CLASS CE2 200A60D7>
>
> CL-USER 36 > (describe (make-instance 'ce2))
>
> #<CE2 200DEB8F> is a CE2
> A      CE2-VALUE
>
> Slots with the same name are merged. CE2 has only
> one slot named A. The initform for CE2 will be used
> when you make an instance of CE2.
>
>
>
> > Thanks,
>
> > Mirko
>
> --http://lispm.dyndns.org/

Thanks Rainer.  It works wonderfully.

Indeed, I did not think of :before.

For future reference, I am assuming your diagram had a typo.  Here is
how I understand the execution order

>   :before c2
>      :before c1
>        primary c2 -> call-next-method -> primary c1
>          :after c1
>             :after c2

Mirko
From: Rainer Joswig
Subject: Re: Can sub-classes initialize-instance modify base-classes slot *before* base's initialize-instance executes?
Date: 
Message-ID: <joswig-4F522B.21135409102008@news-europe.giganews.com>
In article <····························@news-europe.giganews.com>,
 Rainer Joswig <······@lisp.de> wrote:

> In article 
> <····································@b2g2000prf.googlegroups.com>,
>  ·············@gmail.com wrote:
> 
> > I suspect the answer is no, and in which case I will revisit my
> > concept.  But here is the story.
> > 
> > I have a base class that initializes storage.  One of its subclasses
> > needs extra padding around the storage.  The base classes initializes
> > the padding to zero, and the subclasses ought to change that.  Is
> > there some way to specify this within the standard CLOS machinery?
> > 
> > Here is the example code:
> > 
> > (in-package :cl-user)
> > 
> > (defclass base ()
> >   ((dim
> >     :initform 12
> >     :accessor dim)
> >    (padding
> >     :initform 0
> >     :accessor padding
> >     :initarg :padding
> >     :documentation "Padding is necessary for some higher order
> > interpolations")
> >    (storage
> >     :initform nil
> >     :accessor storage)))
> > (defmethod initialize-instance :after ((this base) &key)
> >   (format t "Initializing base ~a~%" this)
> >   (setf (storage this) (make-array (+ (dim this)
> > 				      (padding this))
> > 				   :initial-element 0d0)))
> > 
> > (defclass sub1a (base)
> >   ((dummy
> >     :initform 2d0
> >     :accessor dummy))
> >  (:documentation "This will implement a higher order interpolations
> > that needs padding")
> > 
> > ;; I would like to modify padding here.
> > (defmethod initialize-instance :after ((this sub1a) &key)
> >   (format t "Initializing sub ~a~%" this)
> >   (setf (padding this) 2))
> 
> Sure. Why not. Remember that all :after methods are running.
> 
> CL-USER 26 > (defclass c1 () (a))
> #<STANDARD-CLASS C1 200AFF37>
> 
> CL-USER 27 > (defclass c2 (c1) ())
> #<STANDARD-CLASS C2 200AE0B7>
> 
> CL-USER 28 > (defmethod initialize-instance :after ((object c1) &key) (setf (slot-value object 'a) 'c1-value))
> #<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C1) 200964C3>
> 
> CL-USER 29 > (defmethod initialize-instance :after ((object c2) &key) (setf (slot-value object 'a) 'c2-value))
> #<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C2) 21E2D45F>
> 
> CL-USER 30 > (describe (make-instance 'c2))
> 
> #<C2 21A36597> is a C2
> A      C2-VALUE
> 
> 
> The slot is set twice. first to c1-value and then to c2-value.
> First the :after method for C1 is running, then the :after method
> for C2.
> 
> > 
> > 
> > To get what I want, I need to do
> > > (make-instance 'sub1a :padding 2)
> > but I would prefer to do just
> > > (make-instance 'sub1a)
> > This, of course does not work, because first the base's initialize-
> > instance method is called, which sort-of makes sense.
> 
> But then the :after methods are running. The :after methods
> from the subclass is running later.
> 
> Similar, all the :before methods are running. The :before
> methods from the subclasses are running first:
> 
> For a method like initialize-instance with an object of class C2:
> 
>   :after c2
>      :after c1
>        primary c2 -> call-next-method -> primary c1
>      :before c1
>   :after c2

Wow, I meant:

>   :before c2
>      :before c1
>        primary c2 -> call-next-method -> primary c1
>      :after c1
>   :after c2

Not sure what I was thinking of...


> 
> The value of the primary method for c2 is returned as the value
> for the generic function call.      
> 
> (there are also :around methods)
> 
> > 
> > The first approach looks kind of kludgy, even though Keene (yep, I
> > went to the library and got the CLOS book) suggests using constructors
> > to hide the ugly make-instance details.
> > 
> > In real world, the base class is a an "abstract/virtual" (not sure of
> > the difference) class for a differential equation solver, while the
> > (layered) subclasses are particular instances of the solvers, some of
> > which build on top of others.  The base class provides the basic
> > storage, and methods for storing, accessing, and numerical
> > computations.
> 
> Also remember this:
> 
> CL-USER 33 > (defclass ce1 ()
>                ((a :initform 'ce1-value)))
> #<STANDARD-CLASS CE1 2009B607>
> 
> CL-USER 34 > (describe (make-instance 'ce1))
> 
> #<CE1 20099607> is a CE1
> A      CE1-VALUE
> 
> CL-USER 35 > (defclass ce2 ()
>                ((a :initform 'ce2-value)))
> #<STANDARD-CLASS CE2 200A60D7>
> 
> CL-USER 36 > (describe (make-instance 'ce2))
> 
> #<CE2 200DEB8F> is a CE2
> A      CE2-VALUE
> 
> Slots with the same name are merged. CE2 has only
> one slot named A. The initform for CE2 will be used
> when you make an instance of CE2.
> 
> > 
> > Thanks,
> > 
> > Mirko

-- 
http://lispm.dyndns.org/
From: ·············@gmail.com
Subject: Re: Can sub-classes initialize-instance modify base-classes slot 	*before* base's initialize-instance executes?
Date: 
Message-ID: <8a7d3346-61ce-4e86-b257-129e1f883b27@17g2000hsk.googlegroups.com>
On Oct 9, 3:14 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <····························@news-europe.giganews.com>,
>  Rainer Joswig <······@lisp.de> wrote:
>
>
>
> > In article
> > <····································@b2g2000prf.googlegroups.com>,
> >  ·············@gmail.com wrote:
>
> > > I suspect the answer is no, and in which case I will revisit my
> > > concept.  But here is the story.
>
> > > I have a base class that initializes storage.  One of its subclasses
> > > needs extra padding around the storage.  The base classes initializes
> > > the padding to zero, and the subclasses ought to change that.  Is
> > > there some way to specify this within the standard CLOS machinery?
>
> > > Here is the example code:
>
> > > (in-package :cl-user)
>
> > > (defclass base ()
> > >   ((dim
> > >     :initform 12
> > >     :accessor dim)
> > >    (padding
> > >     :initform 0
> > >     :accessor padding
> > >     :initarg :padding
> > >     :documentation "Padding is necessary for some higher order
> > > interpolations")
> > >    (storage
> > >     :initform nil
> > >     :accessor storage)))
> > > (defmethod initialize-instance :after ((this base) &key)
> > >   (format t "Initializing base ~a~%" this)
> > >   (setf (storage this) (make-array (+ (dim this)
> > >                                     (padding this))
> > >                                  :initial-element 0d0)))
>
> > > (defclass sub1a (base)
> > >   ((dummy
> > >     :initform 2d0
> > >     :accessor dummy))
> > >  (:documentation "This will implement a higher order interpolations
> > > that needs padding")
>
> > > ;; I would like to modify padding here.
> > > (defmethod initialize-instance :after ((this sub1a) &key)
> > >   (format t "Initializing sub ~a~%" this)
> > >   (setf (padding this) 2))
>
> > Sure. Why not. Remember that all :after methods are running.
>
> > CL-USER 26 > (defclass c1 () (a))
> > #<STANDARD-CLASS C1 200AFF37>
>
> > CL-USER 27 > (defclass c2 (c1) ())
> > #<STANDARD-CLASS C2 200AE0B7>
>
> > CL-USER 28 > (defmethod initialize-instance :after ((object c1) &key) (setf (slot-value object 'a) 'c1-value))
> > #<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C1) 200964C3>
>
> > CL-USER 29 > (defmethod initialize-instance :after ((object c2) &key) (setf (slot-value object 'a) 'c2-value))
> > #<STANDARD-METHOD INITIALIZE-INSTANCE (:AFTER) (C2) 21E2D45F>
>
> > CL-USER 30 > (describe (make-instance 'c2))
>
> > #<C2 21A36597> is a C2
> > A      C2-VALUE
>
> > The slot is set twice. first to c1-value and then to c2-value.
> > First the :after method for C1 is running, then the :after method
> > for C2.
>
> > > To get what I want, I need to do
> > > > (make-instance 'sub1a :padding 2)
> > > but I would prefer to do just
> > > > (make-instance 'sub1a)
> > > This, of course does not work, because first the base's initialize-
> > > instance method is called, which sort-of makes sense.
>
> > But then the :after methods are running. The :after methods
> > from the subclass is running later.
>
> > Similar, all the :before methods are running. The :before
> > methods from the subclasses are running first:
>
> > For a method like initialize-instance with an object of class C2:
>
> >   :after c2
> >      :after c1
> >        primary c2 -> call-next-method -> primary c1
> >      :before c1
> >   :after c2
>
> Wow, I meant:
>
> >   :before c2
> >      :before c1
> >        primary c2 -> call-next-method -> primary c1
> >      :after c1
> >   :after c2
>
> Not sure what I was thinking of...
>
Whatever you were thinking of was pretty good, as far as I'm
concerned :-)