Something I'm curious about: Struct accessors created by `defstruct'
normally have names which are the slot names with the class name
prepended. This, of course, is to prevent the name collisions that
would occur if different structure classes happened to share slot
names. In CLOS, however, accessors are generic functions. This
introduces the possibility of using slot names unmodified, i.e. not
prefixed by the class name, as accessor names; the generic-function
mechanism will disambiguate the usage at runtime.
My question to each of you is, do you like to take advantage of this
option, reusing your slot names as accessor names; or do you prefer
the traditional style with the class name prepended? In either case,
why?
-- Scott
Scott Burson <········@gmail.com> writes:
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
I do neither.
Using the same name for a slot and for the accessor is generally a bad
idea, because of the way the package system works. You export
symbols, so if you export the name of the accessor you also export the
name of the slot, which might give the impression that client code is
allowed to use SLOT-VALUE directly.
I find that prefixing the accessor with the class name too verbose,
and often gets me in trouble when I have complicated class
hierarchies.
I have started prefixing the slot name with `%', a tradition that
indicates that something is unusual or dangerous. Thus, I don't
expect to see references to a name starting with `%' anywhere in the
code, except as the name of a slot.
Another recent convention I have seen is to suffix the accessor with
`-of'.
--
Robert Strandh
Scott Burson <········@gmail.com> writes:
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
I've grown to like a third option: naming slot accessors (all
non-boolean "property"-accessing functions, really) <foo>-of.
such names are all of: not obscenely verbose, human reader-friendly,
sort of cute, unlikely to clash with CL symbols.
cheers,
--m
Michael Livshin <······@cmm.kakpryg.net> writes:
> I've grown to like a third option: naming slot accessors (all
> non-boolean "property"-accessing functions, really) <foo>-of.
AOL, exactly what I use.
And I really don't like defstruct-inspired naming - it only makes
it incredibly difficult to remember the names of the accessors.
--
(espen)
In article <··············@gazonk.netfonds.no>,
Espen Vestre <·····@vestre.net> wrote:
> Michael Livshin <······@cmm.kakpryg.net> writes:
>
> > I've grown to like a third option: naming slot accessors (all
> > non-boolean "property"-accessing functions, really) <foo>-of.
>
> AOL, exactly what I use.
> And I really don't like defstruct-inspired naming - it only makes
> it incredibly difficult to remember the names of the accessors.
Why not use completion?
If your accessors are named CLASS-SLOT, typing
CLASS- and getting the completions should be enough
to find what you want.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> writes:
> If your accessors are named CLASS-SLOT, typing
> CLASS- and getting the completions should be enough
> to find what you want.
Except if what you want was defined in a superclass.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
* Rainer Joswig <······@lisp.de>:
> Why not use completion? If your accessors are named CLASS-SLOT,
> typing CLASS- and getting the completions should be enough to find
> what you want.
Except for slots inherited from superclasses.
--
Johannes Gr�dem
Johannes Groedem <····@copyleft.no> writes:
> Except for slots inherited from superclasses.
Hey, you and Peder both took the words out of my mouth :-)
--
(espen)
In article <··············@mort.netfonds.no>,
Johannes Groedem <····@copyleft.no> wrote:
> * Rainer Joswig <······@lisp.de>:
> > Why not use completion? If your accessors are named CLASS-SLOT,
> > typing CLASS- and getting the completions should be enough to find
> > what you want.
>
> Except for slots inherited from superclasses.
* Not if you have a common prefix as mentioned before.
Example:
All accessors for log classes would be named LOG-something.
* You can easily query the Lisp for the superclasses
and provide their accessors as completion, too.
I a good Lisp IDE this would be ten lines of code.
Say: COMPLETE-CLASS-FOR-ACCESSORS
Takes a CLASS name or class object, gets its superclasses (all),
computes the list of accessors of itself and its supperclasses,
removes duplicate names and sorts them.
You would then get a menu to choose one.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> writes:
>> Except for slots inherited from superclasses.
>
>
> * Not if you have a common prefix as mentioned before.
>
> Example:
>
> All accessors for log classes would be named LOG-something.
But with multiple inheritance you're lost (yes, I saw your comment
on mixin classes, but it didn't convince me :-))
Besides, for huge hiarchies, you'd probably end up prepending with
something so general that it's more noise than information.
The only problem I see with the "-of" style is that you sometimes
collide with built-in functions - but TYPE-OF has been the only
source of frustration so far.
--
(espen)
In article <··············@gazonk.netfonds.no>,
Espen Vestre <·····@vestre.net> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> >> Except for slots inherited from superclasses.
> >
> >
> > * Not if you have a common prefix as mentioned before.
> >
> > Example:
> >
> > All accessors for log classes would be named LOG-something.
>
> But with multiple inheritance you're lost (yes, I saw your comment
> on mixin classes, but it didn't convince me :-))
I'm not sure I'm lost. That's what I'd use for larger
class hierarchies. CL-HTTP uses that for example.
> Besides, for huge hiarchies, you'd probably end up prepending with
> something so general that it's more noise than information.
T- ? No, usually it would be WINDOW-, LOG-, TRANSACTION-,
HEADER-, ...
> The only problem I see with the "-of" style is that you sometimes
> collide with built-in functions - but TYPE-OF has been the only
> source of frustration so far.
Also all same-name-methods (in the same package) of different classes
go into a single GENERIC FUNCTION. Which can lead to undesirable
effects if you use general :after, :around or :before methods.
(It can also lead to desirable effects ;-) .)
Not that I would use your proposed naming convention, ;-)
but it certainly sounds useful.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> writes:
>> But with multiple inheritance you're lost (yes, I saw your comment
>> on mixin classes, but it didn't convince me :-))
>
> I'm not sure I'm lost. That's what I'd use for larger
> class hierarchies. CL-HTTP uses that for example.
It's a long time since I looked at CL-HTTP. I used to love it, but I
remember its naming conventions as pretty frustrating...
> Also all same-name-methods (in the same package) of different classes
> go into a single GENERIC FUNCTION. Which can lead to undesirable
> effects if you use general :after, :around or :before methods.
But who uses T- :after/:around/:before methods? (The question is
not entirely rethorical, I'd like to know if someone uses such
methods at all, and why!). I use a lot of very general :around-
etc. methods, but they're always defined on the topmost of
/my/ classes, not on T!
> (It can also lead to desirable effects ;-) .)
:-)
--
(espen)
Scott Burson wrote:
> Something I'm curious about: Struct accessors created by `defstruct'
> normally have names which are the slot names with the class name
> prepended. This, of course, is to prevent the name collisions that
> would occur if different structure classes happened to share slot
> names. In CLOS, however, accessors are generic functions. This
> introduces the possibility of using slot names unmodified, i.e. not
> prefixed by the class name, as accessor names; the generic-function
> mechanism will disambiguate the usage at runtime.
>
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names;
...and initarg name. If there is a clash, find a better name. Someone
offered "time". That is the name of a dimension, not an attribute. That
slot should probably be called "duration". Even if the right name has a
clash, get over it, it's a big language, find another. As for worrying
about exporting slot names and what that says to users of one's code,
jeez, my damn newsreader keeps pulling in messages from comp.lang.c++!
Why? I have enough to think about without changing names of the same
thing, and the prefixing deal (which would not be a memory challenge) is
simply verbose.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Scott Burson <········@gmail.com> writes:
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
Yes, because it is least redundant. Compare, e.g.,
(let ((point (make-instance 'point ...)))
(point-colour point))
with
(let ((point (make-point ...)))
(colour point))
I also use the convention that SLOT-VALUE is for internal access.
Nicolas
P.S.: I would also consider the "-of"-suffix of Michael Livshin to be often
redundant for one-argument functions, e.g. 'length-of', 'dimension-of', ...
Nicolas Neuss <········@mathematik.uni-karlsruhe.de> writes:
> P.S.: I would also consider the "-of"-suffix of Michael Livshin to
> be often redundant for one-argument functions, e.g. 'length-of',
> 'dimension-of', ...
it is only appropriate for one-argument functions in the first place!
it's for "property accessors".
(and, for the record, it was absolutely not me who came up with this
convention).
cheers,
--m
Michael Livshin <······@cmm.kakpryg.net> writes:
> it is only appropriate for one-argument functions in the first place!
> it's for "property accessors".
What I wanted to say is that many one-argument functions can be seen as
yielding a property. Do you only name _accessors_ that way? [For many
slots, I only define the reader and not the whole accessor, because I use
my classes mostly in a functional way. If naming those readers as their
slot is OK, then our styles would probably mix quite well.]
> (and, for the record, it was absolutely not me who came up with this
> convention).
>
> cheers,
> --m
Nicolas
Nicolas Neuss <········@mathematik.uni-karlsruhe.de> writes:
> What I wanted to say is that many one-argument functions can be seen as
> yielding a property. Do you only name _accessors_ that way? [For many
> slots, I only define the reader and not the whole accessor, because I use
> my classes mostly in a functional way. If naming those readers as their
> slot is OK, then our styles would probably mix quite well.]
hmm, I guess my usage of the word "accessor" is confusing, due to CL
distinguishing "accessors" from mere "readers". I mean both here,
since setf-ability is (to my mind, anyway) orthogonal to function
naming.
cheers,
--m
On Sep 4, 5:58 am, Scott Burson <········@gmail.com> wrote:
> Something I'm curious about: Struct accessors created by `defstruct'
> normally have names which are the slot names with the class name
> prepended. This, of course, is to prevent the name collisions that
> would occur if different structure classes happened to share slot
> names. In CLOS, however, accessors are generic functions. This
> introduces the possibility of using slot names unmodified, i.e. not
> prefixed by the class name, as accessor names; the generic-function
> mechanism will disambiguate the usage at runtime.
>
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
>
> -- Scott
Very interesthing thread. I started with using only slot name, but hit
the wall very quickly with functions that already exist and have the
same name as my slot , for example time. Now I'm still searhing my own
naming conevention.
Anyway other posters gave me a lot of ideas for considering.
On Tue, 04 Sep 2007 10:26:54 -0000, Slobodan Blazeski
<·················@gmail.com> tried to confuse everyone with this message:
>On Sep 4, 5:58 am, Scott Burson <········@gmail.com> wrote:
>> Something I'm curious about: Struct accessors created by `defstruct'
>> normally have names which are the slot names with the class name
>> prepended. This, of course, is to prevent the name collisions that
>> would occur if different structure classes happened to share slot
>> names. In CLOS, however, accessors are generic functions. This
>> introduces the possibility of using slot names unmodified, i.e. not
>> prefixed by the class name, as accessor names; the generic-function
>> mechanism will disambiguate the usage at runtime.
>>
>> My question to each of you is, do you like to take advantage of this
>> option, reusing your slot names as accessor names; or do you prefer
>> the traditional style with the class name prepended? In either case,
>> why?
>>
>> -- Scott
>
>Very interesthing thread. I started with using only slot name, but hit
>the wall very quickly with functions that already exist and have the
>same name as my slot , for example time. Now I'm still searhing my own
>naming conevention.
In that case, I simply shadow TIME. It's never used outside of REPL anyway.
If I had to remember which accessor corresponds to which slot, I'd quickly
lose any remaining sanity.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
In article <························@k79g2000hse.googlegroups.com>,
Scott Burson <········@gmail.com> wrote:
> Something I'm curious about: Struct accessors created by `defstruct'
> normally have names which are the slot names with the class name
> prepended. This, of course, is to prevent the name collisions that
> would occur if different structure classes happened to share slot
> names. In CLOS, however, accessors are generic functions. This
> introduces the possibility of using slot names unmodified, i.e. not
> prefixed by the class name, as accessor names; the generic-function
> mechanism will disambiguate the usage at runtime.
>
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
>
> -- Scott
* naming the accessors like the slots is kind of ugly.
You may have two classes with both with a slot of
the same name.
Since methods are organized into generic functions,
the two accessor methods would be organized into
one generic function - which I find not that optimal
from the style point of view.
This style is often used for single class
definitions without hierarchy.
* prepending the class name is also kind of ugly.
Say, you have a class SPREADSHEET-PREVIEW-WINDOW
and a slot COMMAND-PANE, then you get
SPREADSHEET-PREVIEW-WINDOW-COMMAND-PANE .
Ugly.
A little bit better would be to write:
SPREADSHEET-PREVIEW-WINDOW.COMMAND-PANE
So you can see what is the class name and
what is the slot name. That would unfortunately
make it look like the dot is something special
and that you could write
SPREADSHEET-PREVIEW-WINDOW.COMMAND-PANE.HEIGHT
to access a component of the command pane.
But that would be a new mechanism.
* Another option would be to use a common prefix for a
'cluster' (say, a hierarchy) of classes.
So instead using SPREADSHEET-PREVIEW-WINDOW-COMMAND-PANE,
one could write something like WINDOW-COMMAND-PANE,
or WINDOW.COMMAND-PANE .
Another example would be that you have a multitude
of LOG (transaction, condition, whatever) classes
with the root class BASIC-LOG .
All accessors in all subclasses
would have the common prefix LOG- .
Like LOG-EVENT-TIME .
This also applies to mixin style programming. Sometimes
you want the mixin classes only be used with
such a cluster of classes. Say, you have a class
NOTIFICATION-MIXIN, which would only be used
in combination for LOG classes, then the mixin
may also get (some) accessors with LOG- prepended.
--
http://lispm.dyndns.org
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> * naming the accessors like the slots is kind of ugly.
>
> You may have two classes with both with a slot of
> the same name.
I can easily see this happen in different packages, but why would you
use the same name for unrelated concepts in the same package?
The thing that bugs me about the <slot>-OF convention that some have
recommended is that it's different from the convention used in the base
language. E.g. we have CAR and CDR, not CAR-OF and CDR-OF, to access
the slots of a cons. And notice that this is despite the fact that in
prose we often refer to "car of" and "cdr of" things.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> The thing that bugs me about the <slot>-OF convention that some have
> recommended is that it's different from the convention used in the base
> language. E.g. we have CAR and CDR, not CAR-OF and CDR-OF, to access
> the slots of a cons. And notice that this is despite the fact that in
> prose we often refer to "car of" and "cdr of" things.
I see your point, but you've actually just explained my main rationale
for using "-OF" instead of just the slot names :-) - Since the base
language doesn't use it (except for TYPE-OF and CLASS-OF), I get very
few function name conflicts. So I can keep simple slot names like LAST
without getting into trouble.
--
(espen)
Scott Burson wrote:
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
I try to go for Rainer's approach (prefixed, but with fewer prefixes
than class names), but I find it makes me slow because I feel I'm forced
to work out in advance what the major groups of classes are instead of
letting them evolve naturally. Perhaps with better editor support for
refactoring this would be less of an issue. I wrote ("ranted" might be
the better verb) about this at http://ww.telent.net/diary/2006/2/#24.2759
You might want to read http://cybertiggyr.com/gene/80-closminded/ too
-dan
From: Richard M Kreuter
Subject: Re: Style survey: CLOS accessor names
Date:
Message-ID: <87ir6qco3d.fsf@progn.net>
Scott Burson <········@gmail.com> writes:
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either
> case, why?
One advantage of generic functions named with some prefix (maybe a
class name, or a protocol or subprotocol name) is that such names
offer more room for gradual change.
For example, let's say you have a program that has some classes and
that there's some function that could be construed to do something
equivalent for each class. So you might provide the function as
single generic function with several methods, like this:
(defgeneric foo (thing))
(defmethod foo ((thing c1)) ...)
(defmethod foo ((thing c2)) ...)
(defmethod foo ((thing c3)) ...)
or you might do it as several distinct generic functions, like this:
(defgeneric c1-foo (thing))
(defmethod c1-foo ((thing c1)) ...)
(defgeneric c2-foo (thing))
(defmethod c2-foo ((thing c2)) ...)
(defgeneric c3-foo (thing))
(defmethod c3-foo ((thing c3)) ...)
Now suppose that later on you want to use instances of some other type
as designators for instances of the program's classes; you might want
to support integer-valued primary keys in a relational database, or
string-valued identifiers from some externally regulated namespace.
If you've picked the longer names, then you can add methods
specialized on the other type that invoke the function on the
designated instance, and unless your program was restrictive about
what types of objects it passed along, everything should automagically
support the new type throughout. If you've picked the shorter names,
it becomes harder to do this: you can write several wrappers that
invoke the generic function on the designated instances, but then
you'll have to find and update all callers of the underlying generic
functions to use your wrappers, or else some pathways through the code
won't do the right thing on the new type you mean to support.
--
RmK
On Sep 3, 8:58 pm, Scott Burson <········@gmail.com> wrote:
> My question to each of you is, do you like to take advantage of this
> option, reusing your slot names as accessor names; or do you prefer
> the traditional style with the class name prepended? In either case,
> why?
Thanks for the replies.
My own practice has been to name accessors the same as slots. My
thinking is very close to that in the Tom Moore essay that Dan posted
a link to; I've even, on occasion, written a generic function that had
some of its methods defined as accessors, and others with `defmethod'.
I would have guessed that naming accessors the same as slots was
pretty much standard CLOS practice; certainly the designers of CLOS
seem to have specifically intended to make it possible, suggesting
that they (or some of them, anyway) thought it was a good idea. But
lately, on a few occasions, I've noticed someone prepending the class
names -- I mostly don't recall where; in code I've downloaded from
somewhere, probably -- and started to wonder what was really common
practice. Hence this little survey.
Seeing the diversity of opinions, I'm not sure there's anything we can
all agree on except that the choice is not as straightforward as one
might hope. I am aware, for instance, that I might have two classes
that want to use the same slot (and therefore accessor) name for two
concepts that are sufficiently distinct that the overloaded accessor
name risks confusion; this hasn't been a problem in practice, though.
In fact I think it's always been the case in my experience that all
slots with the same name have had the same type. However, I haven't
written anything very large with CLOS, nor have I used it in a team
situation.
As for the specific proposals, I don't care for "-of", for the reasons
Barry gave. The "%" convention is intriguing; I could see using that
in some situations to emphasize that `slot-value' is dangerous. As
for the carefully chosen set of a few prefixes for many classes, I'll
have to think about that, but it seems most likely to be useful for
large systems that have to be substantially designed in advance; I
wouldn't even try to do it for exploratory programming.
Thanks again,
Scott
On 2007-09-05, Scott Burson <········@gmail.com> wrote:
> Seeing the diversity of opinions, I'm not sure there's anything we can
> all agree on except that the choice is not as straightforward as one
> might hope.
In my view it is not just that different people prefer different
conventions. Being a matter of style, it is simply a decision to be
made on a case-by-case basis.
Kenny has it absolutely right when he says "If there is a clash, find a
better name".
Sometimes functions are in a package not even meant to be imported into
other packages. For example, cxml puts DOM functions into a package
called DOM which does not import the COMMON-LISP package. So DOM:LENGTH
is not a name conflict. In this case, there is no point prefixing
symbols with "DOM-". (Apparently Franz chose the name
NET.XML.DOM:DOM-LENGTH for the same function. Even if you import that
package, DOM-LENGTH is still not shorter than DOM:LENGTH would have
been, and the long package name for a well-known specification is
redundant.)
For the DOM alternative implemented by cxml-STP [*] I made a different
choice. It is an API designed specificially for Lisp, so I took care to
avoid name clashes. For example, there are many functions related to
child nodes, so there is FIND-CHILD rather than FIND, and NTH-CHILD
rather than NTH, avoiding the similar names specified by Common Lisp
without adding the class name NODE as a prefix.
For slot readers, there are LOCAL-NAME, NAMESPACE-URI, NAMESPACE-PREFIX,
and QUALIFIED-NAME. The last one is actually computed at run time from
the others. Surely nobody would demand the first three to be named -OF
and the last one not? Naming them all -OF would be even worse.
Yet sometimes a prefix makes a lot of sense, which is why I disagree
with the recommendation to -never- use a prefix based on the class name.
Using yet another cxml-related library as an example, there is the
Relang NG implementation cxml-rng [**] which has classes PATTERN and
NAME-CLASS (with various subclasses), and SCHEMA (no subclasses). In
this case, I find SCHEMA-START at lot clearer than START would have
been, even though the prefix is not strictly necessary. As an example
where the class name of the superclass is the right prefix, look at
PATTERN. There are several subclasses of PATTERN with exactly one
child, so naming this slot reader PATTERN-CHILD gives all of them the
same name. And on the other hand, there is an example in the same
library where using the name of the different subclass as the prefix
feels right, namely in the case of `name classes' where I find it much
clearer to have different readers ANY-NAME-EXCEPT and NS-NAME-EXCEPT
because it makes it easy to see in the symbol index which name classes
have an `except' case.
> As for the specific proposals, I don't care for "-of", for the reasons
> Barry gave.
Usually I see no reason to document which of my "accessors" are actually
accessing slots directly, and which of them are ordinary functions. I
document functions, not slots. So any convention that requires me to
give slot accessors a special name specifies my API too tightly. If I
have a slot today that I would like to implement as an ordinary pair of
function and setf function tomorrow instead, users should not notice the
difference. And naming -every- single-argument function foo-OF just
because I can also seems extremely silly.
David
[*] http://www.lichteblau.com/cxml-stp/doc/pages/cxml-stp.html
[**] http://www.lichteblau.com/cxml-rng/doc/index.html
On Sep 5, 5:48 am, David Lichteblau <···········@lichteblau.com>
wrote:
> In my view it is not just that different people prefer different
> conventions. Being a matter of style, it is simply a decision to be
> made on a case-by-case basis.
Good point, backed up by compelling examples.
-- Scott