[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: mop questions
- From: firstname.lastname@example.org
- Date: Wed, 31 Oct 1990 03:12:55 PST
- Cc: email@example.com
- In-reply-to: "Gregor Kiczales's message of Tue, 30 Oct 1990 18:20:49 PST <90Oct30.firstname.lastname@example.org>"
Gregor and Jim,
Thanks for your prompt replies. There are a couple of issues I wanted
to ask about in some more depth.
2. Why are slot readers/writers/accessors created and bound inside of
INITIALIZE-INSTANCE instead of in their own defining forms (eg
DEFREADER, DEFACCESSOR, etc.)?
I don't know what this means. CLOS doesn't have forms like DEFREADER.
It could of course, but doesn't. In addition, CLOS requires
redefinition of class with different accessors, readers or writers to
remove the old ones and add the new ones.
If, as you may be suggesting, DEFCLASS converted readers and writers to
DEFREADER and DEFWRITER, it would require that defclass did all the work
of keeping track of new and old definitions. This doesn't fit the
conceptual model we are trying to use that the state of class definition
is entirely in the metaobject. It would also prevent the functionality
of readers and writers from being available in classes created
anonymously by MAKE-INSTANCE.
The reason I ask these questions, of course, is in the context of
EuLisp and TELOS. In EuLisp we would like function bindings - and
especially important ones like slot accessors - to be defined entities
known to the compiler. There is also a large interest in factoring
complex behavior like that provided by DEFCLASS into a composition of
simpler but well-specified behaviors. Adding defining forms for these
rather special functions seems like a natural way to achieve these
goals. So what I'd like to know primarily is if you think this is a
reasonable approach. In particular, I'm not interested in challenging
CLOS's decisions, just in figuring out the best way for EuLisp.
Also in EuLisp class redefinition is not such an important issue. The
interactive case is seen as special, and special processing rules can
apply. What we are largely concerned with (at least on this side of
the Channel) is module compilation.
5. Is CLOS supposed to detect when new methods are added to reader or
writer generic functions, when those new methods do not access the
same slot as the original generic function? This question arises from
the existence of the function METHOD-SLOT-NAME.
I don't understand this question. When you add a new method to a
generic function, you just add it. Whether the generic function
previously had only automatically created reader or writer methods
doesn't enter into it. There is no reason why two automatically
generated readers methods, on the same generic function, can't read
slots with different names.
I apologize for this question. I made some bad assumptions based on
some slightly obscure language in 88-002R page 2-28 and a stronger
TELOS restriction on generic functions. In the CLOS specification,
"The :method-class option is used to specify that all methods on this
generic function are to have a different class from the default
provided by the system..." I assumed that all methods on a generic
function were intended to have the same class. This is a useful
restriction for certain purposes, and it is embodied in TELOS. (The
abstraction point is a good one and argues against the restriction.)
However, I see in the latest MOP pages 3-74 to 3-76 language which
implies that this is not in fact a CLOS restriction. Anyway, assuming
the restriction, it makes sense to think about reader and writer
generic functions, and not just reader and writer methods. The
existence of METHOD-SLOT-NAME then prompted me to wonder if you
intended it to be an error to have different methods on such a generic
function access different slots. In fact, I found it unusual that
there would be such an error, thus the question.
6. Do you intend there to be any sort of correspondence between slot
allocation as given by the :ALLOCATION slot option and the class of
the slot definition metaobject? I don't think so, but is this at
least a viable implementation approach?
The MOP doesn't do this. It treats allocation as state associated with
the slot definition metaobject rather than as determining the class of
the slot definition metaobject. We could have done it differently, but
the currents scheme works pretty well for now.
Going the other way also gets too quickly into unresolved issues about
programming with dynamically created classes.
What issues are you thinking about here? These questions about slot
definition metaobjects are particularly interesting to me, since it is
one of the areas in which TELOS differs the most from CLOS.
7. Would the intended CLOS way to implement, for example, slot facets
be with new class metaobjects as we see in section 3.3 of AMOP, or by
defining new slot definition metaobject classes? If the answer is the
former, what would be a good reason to do the latter?
The AMOP does this by defining both a new class metaobject class and a
new slot definition metaobject class.
The version of the AMOP that I have does not discuss slot definition
Conceptually, the new class of
slot definition metaobject is to say "it's OK to have an allocation you
haven't seen before." The new class of class metaobject is to say "here
is a kind of class which implements its instances as having these new
kinds of slots." So, both are needed, they serve complementary roles.
So do you see a class as having only one kind of slot definition for
all of its slots? One of the goals of the TELOS MOP was the ability
to mix-n-match slot definition metaobjects of different classes within
the same class metaobject. I think this is only a partial success in
the current version; the EuLisp community is working on refinements as
Thanks again for your thoughtful (dare I say `reflective'?) answers.
PS I received two copies of each of your messages, as well as a
message from the PARC postmaster with the following error:
A copy of your message is being returned to you because one or more of
the addresses you specified could not be recognized as addresses that are
understood by, or reachable from, this system.
error: err.unresolvable: email@example.com.ARPA
error: err.unresolvable: firstname.lastname@example.org.ARPA
error: err.unresolvable: email@example.com.ARPA
error: err.unresolvable: firstname.lastname@example.org.ARPA