[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More direct question about naming issues for GOOPS based module APIs.
From: |
Rob Browning |
Subject: |
More direct question about naming issues for GOOPS based module APIs. |
Date: |
Thu, 13 May 2004 01:47:20 -0500 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Given that I'm relatively new to GOOPS (though fairly knowledgable wrt
CLOS), I'd just like to ask directly: what do people feel are the
relevant considerations when choosing the exported names for a GOOPS
based module?
For example, although *I* tend to be comfortable with longer function
names like gw-argument-types, gw-typespec, or even all-gw-types, when
a module uses GOOPS, one could (and people have) made the argument
that
(all-gw-types my-typespec)
is just unnecessarily verbose as compared to
(all-types my-typespec)
because GOOPS dispatches on the class of my-typespec. One could
further argue that as long as you're careful with your argument names,
you end up with code that's equally readable in either case.
(Although I would still be concerned that with the latter approach, it
may be much more difficult to locate all calls to a given method,
i.e. "fgrep '(close' *" vs "fgrep '(close-wrapset' *".
As further examples, I wasn't sure about were exactly what the risks
are with respect to import collisions, say between a module's exported
generics and the existing bindings of the importer, nor what the risks
are, if any, regarding accidental shadowing, etc.
I'd also be interested in any stylistic opinions.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
- More direct question about naming issues for GOOPS based module APIs.,
Rob Browning <=