Newsgroups: comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!nntp.crl.com!pacbell.com!gw2.att.com!nntpa!ssbunews!iexist!not-for-mail
From: clarisse@iexist.flw.att.com (55437-olivier clarisse(haim)463)
Subject: Re: CLOS instance initialization
Message-ID: <D9EFuG.AzM@ssbunews.ih.att.com>
Originator: clarisse@tenet
Sender: clarisse@iexist (55437-olivier clarisse(haim)463)
Nntp-Posting-Host: tenet.flw.att.com
Organization: AT&T
References:  <1995May29.013140.22148@franz.com> <D9ED46.9s3@ssbunews.ih.att.com>
Date: Tue, 30 May 1995 16:15:52 GMT
Lines: 69


I am resending this because my mailer keeps restricting the distribution...

In article <1995May29.013140.22148@franz.com>, kem@math.ufl.edu (Kelly Murray) writes:
|> 
|> > Does anyone know of a forum where folks are discussing CLOS?
|> 
|> Ok, let's talk about CLOS.
|> 
|> I'd like to get some discussion about how instances are initialized,
|> and whether people think it should be changed.
|> 
|> One difficulty with initialization of instances is that an application
|> can only really define :after methods on initialize-instance.
|> 
|> In many cases, it makes sense to run :before methods during initialization,
|> so that a subclass can do some stuff before its inherited superclasses
|> do their thing.  But you can't do this since only :after methods can
|> be defined, and hence run after the superclass methods run.
|> 
|> To get around this, an application will often define a standard
|> initialization method which is called in the :after initialize-instance
|> method, and all the initializations are really defined on this method.
|> A typical name might be "new-instance" or "initialize".
|> 
|> I was wondering how pervasive this is, and whether it might make
|> sense to standardize on this, and changing make-instance
|> to be defined to call another method after calling initialize-instance:
|> 
|> (defmethod make-instance ((class standard-class) &rest args)
|>    (let* ((initargs (default-initargs class args))
|>           (instance (allocate-instance class initargs))
|>      (apply #'initialize-instance instance initargs)
|> 
|> Anyone have an opinion or experience with how they do instance
|> initializations? 
|> 
|> -Kelly Murray    kem@franz.com    Franz Inc.  http://www.franz.com

Yes, we've had similar concerns, but I am not sure the above provides
a general enough solution. In many cases the application code also
needs to massage the &rest arguments even before "allocate-instance"
is called. We found that using the following code "pattern" resolves
that particular issue. Now, it seems one would have to uses a hierarchy
of meta classes that somewhat parallels the object hierarchy to get
the :before effect you mentioned. But doesn't that give you more
flexibility? After all :before is usually not much better than :after for
very long... [Why is there only one object hierarchy in object systems?]

(defclass your-meta (standard-class) ())

(defmethod validate-superclass ((class your-meta) (superclass standard-class))
  t)

(defclass your-object (costume component)
  (...)
  (:metaclass your-meta))

(defmethod make-instance :around ((class meta-actor)
				  &rest initargs)
  ;; Some code
  (... (call-next-method))
  ;; Some more code
)
-- 
----------------
Olivier Clarisse
Member of Technicall Staff
AT&T Bell Laboratories
