[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLX draft 3 revisions
Date: Thu, 14 May 87 08:57:10 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
Thanks for your response. I hadn't thought about accessors like
HEIGHT differing by their units, but differing in concept (e.g. one
application's generic-function DISPLAY which takes a window and
returns its associated display object, and another application's
DISPLAY which takes an object, and a stream and draws the object). I
didn't really consider the former as requiring different accessors,
but the latter should obviously be separated by packages,
accessor-prefixes or individual names for the two operations. My gut
feeling was that prefixes shouldn't be used unless needed because they
ruin the genericness of the accessor (why should I have separate
functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?).
The need to distinguish is clear. The question is which language structure
is appropriate to realize the distinction.
A number of concepts, such as height and width, can be viewed as "the same"
for a number of different clx objects. Thus, it makes sense to use one
symbol to denote the concept, and thus to have one function name apply to a
number of different clx classes. By placing such symbols in the clx
package, different applications are not precluded from using symbols with
the same name, e.g., arboretum:height, to identify different concepts.
A basic problem with function names that include class names, such as
font-height, is that it is bad for extensibility. When subclasses of the
existing class are defined, e.g., adobe-font, users of those subclasses
will have to remember which ancestor class must be used to construct the
name of the function. This makes such systems more difficult to learn and
increases the incidence of trivial but annoying programming errors.
A possible reason for retaining class-specific accessor names is to achieve
maximal efficiency. If that is indeed the case, then both the "generic"
functions and the class-specific functions should be available.