[pro] When to use SLOT-VALUE...
Daniel Weinreb
dlw at itasoftware.com
Wed Dec 1 14:53:40 UTC 2010
You considered the idea that when you write a library (internal
module, whatever) that defines a new type of Lisp object, it should
not necessarily be apparent to the caller whether the implementation
of objects of that type happen to use CLOS.
Hans: Of course, one may want to argue that DEFCLASS forms should not
be considered to be an interface definition. Instead, one could call
for a series of DEFGENERIC forms to define the external interface of
some "module" and make class definitions be internal.
In addition to this, you'd use a factory function, rather than having
the client call make-instance, to hide the CLOS nature of the type.
I agree with you about this, except that I would go farther and use
packages.
In fact, I wrote a library in this style, called fhash. It creates an
abstraction that implements a map, just like Common Lisp hash-tables,
except that internally it uses linear search when the number of items
is small, and upgrades to to a real hash table when the number of
items gets large.
This is very much like what Hans is talking about, with one slight
difference. In the fhash library, I took the position that Common
Lisp's mechanism for encapsulation is NOT CLOS, not object-oriented
programing, but packages.
The packge declaration says:
(:export
#:fhash-table
#:make-fhash-table
#:getfhash
#:putfhash
#:remfhash
#:clrfhash
#:mapfhash
#:fhash-table-p
#:fhash-table-count
#:fhash-table-size
#:fhash-table-test
#:with-fhash-table-iterator)
More about why using packages is right, in subsequent
mail, since that could turn into a separate thread.
-- Dan
Hans Hübner wrote:
>
> Hi,
>
> The company I work for has a Common Lisp style guide that generally
> disallows using SLOT-VALUE. Instead, accessor should be used so that:
> BEFORE and :AFTER methods are always invoked when accessing a slot.
> Generally, I think this is a good idea when looking at classes and
> instances from the outside. Slots should be considered as being an
> implementation detail, and users (i.e. client code and derived class
> methods) should not make assumptions about how functionality is
> implemented.
>
> Now, I often have the need for class instances that are constant in
> some respect, i.e. some properties of the instance that are
> implemented using slots can't directly be changed. I often declare
> such slots havin only a: READER in the class definition, which makes
> the read-only nature of this slot apparent right away.
>
> Of course, such slots need to be initialized somehow. An :INITARG
> sometimes does the trick, but it is more common that the value of such
> slots is calculated and recalculated during the lifetime of the
> instance, and as such the slot's value must be set.
>
> Now, from the perspective of seeing the class declaration as
> documenting the visible behavior of instances of a class, it does not
> seem to be proper to declare an accessor to be used in class-internal
> code so that the slot's value can be updated. Instead, I think that
> it is better to use SLOT-VALUE to mess with the guts of an instance
> from code that is part of the guts itself.
>
> Of course, one may want to argue that DEFCLASS forms should not be
> considered to be an interface definition. Instead, one could call for
> a series of DEFGENERIC forms to define the external interface of some
> "module" and make class definitions be internal. From a more practical
> perspective, though, class definitions in CL serve both as interface
> and implementation definition, thus it seems to be appropriate using
> the mechanisms provided by CLOS to support both uses.
>
> How do others use or avoid SLOT-VALUE? Is it frowned upon in your
> company's or project's (verbal) style guide?
>
> Thanks for your input,
> Hans
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20101201/4909231d/attachment.html>
More information about the pro
mailing list