In article <··········@pravda.cc.gatech.edu> ·····@cc.gatech.edu (Lyman S. Taylor) writes:
The namespace control construct is totally detached from the object
system. If you want "public"/"private" declarations you'll have to
make use of the package construct. Create a package and export only
those methods and slot accessors ( which are actually methods) to
the "external world". The private stuff remains unexported.
Admittedly the protection provided can be subverted much more easily
than the protection provided by C++/Java. However, the truely dedicated
can subvert just about any barrier.
The protection provided is only to the extent that it warns the programmers
that they are referencing internals. Not a bad philosophy, IMHO, since it
does allow life to continue smoothly in situations where some important
construct had been overlooked by the original programmer.
> 6. What I want to do eventually is the following: right now I have a
> struct dated-list with has 3 slots: list, date-accessor and
> value-accessor, which allows me to treat uniformly, say, a list of daily
> wind speed (defstruct wind date speed) and a list of daily temperatures
> (defstruct temperature date temp). I guess I will need a (DEFCLASS
> DATUM (DATE) VALUE) and (DEFCLASS TEMPERATURE (DATUM) TEMP), but I want
> TEMP in TEMPERATURE to be identical to VALUE in DATUM. What do I do?
.....
>OK, let me rewrite your class definitions, which will hopefully clear out
>my slight confusion and answer your question...
>
>(defclass dated-datum ()
> ((date :initarg :date :reader date)
> (value))) ; The means for reading/writing this are subclass dependent
>
>(defclass daily-temperature (dated-datum)
> ((value :initarg :temperature :accessor temperature)))
>
>(defclass daily-wild (dated-datum)
> ((value :initarg :speed :accessor speed)))
I think you need create two methods bound to the generic VALUE in addition
to the above definitions:
(defmethod value ( (obj daily-temperature))
(temperature obj))
(defmethod value ( (obj daily-wind ))
(speed obj))
In short you can add whatever uniform interface you want to these classes
that is independent of the actual slot names.
Or you can attach a reader/accessor slot to the dated-datum
object... Something I left out for reasons given below.
That way you can write a something like
(mapcar #'value (list obj1 obj2 obj3 ))
where obj1, obj2, obj3 are all daily-datum subtypes.
or
(defmethod value-add ( (obj1 daily-datum) (obj2 daily-datum ) )
(+ (value obj1) (value obj2)))
I must however add that this is not the best way for demonstrating the need
for the value reader. I doubt you would ever want to add wind speed and
temperature. This is IMHO where CLOS excels - it's very easy to provide
accessors that present the programmer with the right abstractions. If, for
instance, you decide that providing a value accessor is likely to lead to
inappropriate abstractions that hide instances where the program might be
adding wind speed and temperature, you can easily choose to not offer that
abstraction.
There are still other ways for uniform access available, such as using the
function slot-value, but these ought to be used with care for entirely
different reasons. They circumvent whatever interface may have been
provided for the regular read/write operations (such as through :before or
:after method combinations), and cause your code to break in strange and
exciting new ways.
Sunil