[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on the gray book
- To: Gregor Kiczales <email@example.com>
- Subject: Re: Comments on the gray book
- From: kanderso@DINO.BBN.COM
- Date: Mon, 5 Nov 1990 18:20:31 PST
- Cc: Moon@stony-brook.scrc.symbolics.COM, mop@arisia.Xerox.COM
- In-reply-to: "Your message of Mon, 05 Nov 90 11:05:24 -0800. <90Nov5.firstname.lastname@example.org>"
Date: Mon, 5 Nov 1990 11:05:24 PST
From: Gregor Kiczales <Gregor@parc.xerox.com>
Subject: Re: Comments on the gray book
Date: Mon, 5 Nov 1990 08:25:00 PST
One more specific comment is that although efficient implementability
is mentioned as a design goal, I don't think the book really touches
on what is necessary to achieve that, which in my opinion depends
fundamentally on keeping the programmer at arm's length from the
implementation through the use of abstraction.
This is a real concern, and one which is fundamental to the value of
this work. Can you say a little more about what you would like us to
say? Your comments seem to be about both the presention (AMOP) and the
design (MOP), but I can't distinguish the two sets of comments clearly
enough to see what you are asking for.
Although i've only read to page 67, let me add a comment about AMOP.
I also got caught short trying to skim things, finding i have to go
back and check things out more carefully. I don't consider it a flaw
in the manuscript, however. I had missed the fact that method objects
had body slots. I just assumed they have functions, i guess. Then in
section 1.7.3 imaginary functions inside eval get called, and i start
not to feel so good. Footnote 16 is encouraging, but it almost made we
want to go read the software in Appendix B.
I think it is OK to be a bit vague in this section since things start
to get vague by the last paragraph of page 36 when it is clear that we
are inside the funcalling mechanism when somehow
apply-generic-function gets called. I'd rather see you defer
discussion about applying a method than see you call eval and
apologize for it.
What will C++ and Self people think if we don't make it clear that
CLOS can be implemented relatively efficiently?