Sometimes when I read the various CLOS facilities I wonder whether the standards committee got a bit too "trigger happy" in adding features
and whether anyone has a use for them. So I was wondering :
1. Has anyone used method combinations other than the standard one ?
In particular any of those in "7.6.6.4 Built-in Method Combination Types" ?
2. Have you ever defined your own method combinations using DEFINE-METHOD-COMBINATION ? If yes , did they take a lambda list ?
I mean the part in the syntax define-method-combination name lambda-list .
Do you happen to know whether any Lisp dialects leading up to Common Lisp had object systems providing facilities similar to the above ?
1. Has anyone used method combinations other than the standard one ?
In particular any of those in "7.6.6.4 Built-in Method Combination Types" ?
2. Have you ever defined your own method combinations using DEFINE-METHOD-COMBINATION ? If yes , did they take a lambda list ?
I mean the part in the syntax define-method-combination name lambda-list .
I am profligate consumer of the wrapping-standard
method combination which does (think I originally defined my own before I
had found that one).
Spiros Bousbouras <spibou@gmail.com> wrote:
1. Has anyone used method combinations other than the standard one ?
In particular any of those in "7.6.6.4 Built-in Method Combination Types" ?
Yes. progn, and, or for instance are very useful, probably have also used append and/or list.
2. Have you ever defined your own method combinations using DEFINE-METHOD-COMBINATION ? If yes , did they take a lambda list ?
I mean the part in the syntax define-method-combination name lambda-list .
Yes and yes. Well, I am profligate consumer of the wrapping-standard
method combination which does (think I originally defined my own before I
had found that one).
I am profligate consumer of the wrapping-standard
method combination which does (think I originally defined my own before I had found that one).
Is worth pointing out that is easy to experimentally check that method combinations such as above have no run-time overhead.
Can you say more like what you were writing ? Because personally I
can't think of an occasion where I would find the operator method combinations useful but I wouldn't be able to achieve the same
functionality in some other way , likely a more straightforward one.
Do you mean :around methods ? These only take :most-specific-first or :most-specific-last arguments. You actually had a use for those ?
Can you say more like what you were writing ? Because personally I can't think
of an occasion where I would find the operator method combinations useful but I wouldn't be able to achieve the same functionality in some other way , likely
a more straightforward one.
Do you mean :around methods ? These only take :most-specific-first or :most-specific-last arguments. You actually had a use for those ?
Is worth pointing out that is easy to experimentally check that method
combinations such as above have no run-time overhead.
I would imagine that depends on the implementation.
Spiros Bousbouras <spibou@gmail.com> writes:
Sometimes when I read the various CLOS facilities I wonder whether the standards committee got a bit too "trigger happy" in adding features
and whether anyone has a use for them. So I was wondering :
1. Has anyone used method combinations other than the standard one ?
In particular any of those in "7.6.6.4 Built-in Method Combination Types" ?
2. Have you ever defined your own method combinations using DEFINE-METHOD-COMBINATION ? If yes , did they take a lambda list ?
I mean the part in the syntax define-method-combination name lambda-list .
Do you happen to know whether any Lisp dialects leading up to Common Lisp had
object systems providing facilities similar to the above ?
There is an implementation of the Eiffel language design by contract as
a custom method combination. I don't think it's ever been used in anger
for a large system but it shows the flexibility.
Spiros Bousbouras <spibou@gmail.com> rote:
Can you say more like what you were writing ? Because personally I
can't think of an occasion where I would find the operator method combinations useful but I wouldn't be able to achieve the same functionality in some other way , likely a more straightforward one.
Caution here: define straightforward. If you're uncomfortable with
method combinations, you may find something else more straightforward,
just because you're not used to method combinations enough.
Disregarding subjectivity (personal experience, style preference,
etc.) as much as possible, I would say this: method combinations allow
you to express a different dispatch algorithm in a declarative way,
rather than in an imperative one. Consequently, there is something I
grew more and more vigilant about over the years: every time I start
using CALL-NEXT-METHOD and friends (which /may/ appear more
straightforward in some sense), I ask myself whether or not I wouldn't
be starting to implement a different combination without actually
realizing it, and most of the time, I am. Now, whether or not it's
worth the trouble to go declarative is also a matter of taste, to some
extent, but IMO, mixing dispatch code and actual methods code together
is never a good think for SoC, and software engineering in general.
Apart from that, yes, for simple cases you may want to avoid the
method combination artillery altogether, but hell, you may also want
to avoid generic functions and use a couple of TYPECASE calls
instead...
Do you mean :around methods ? These only take :most-specific-first or :most-specific-last arguments. You actually had a use for those ?
I have an example in Clon (clon/core/src/output/sheet.lisp). In
general, yes, I find the operator-based standard method combinations
quite usefull (although preferably extended with :before / :after / and
:around).
More recently, I developed a pretty elaborate (but it's only 10 lines
long, so in fact it's pretty straightforward ;-)) method combination
for Declt 4, in the documentation rendering code. I don't have the
time to explain it here right now, but you can find it in
declt/core/src/doc/cod.lisp currently. Trust me on this, thanks to
that, the documentation code became so much cleaner than in version
3...
Do you happen to know whether any Lisp dialects leading up to Common Lisp had object systems providing facilities similar to the above ?
CommonLoops is practically a superset of New Flavors.CommonLoops
andFlavors share the notion of generic function. In developing
CommonLoops we have included the Flavors mechanism for user-defined method combination.
On Wed, 01 Jun 2022 21:36:30 +0200
Lieven Marchand <mal@wyrd.be> wrote:
Spiros Bousbouras <spibou@gmail.com> writes:
Sometimes when I read the various CLOS facilities I wonder whether the
standards committee got a bit too "trigger happy" in adding features
and whether anyone has a use for them. So I was wondering :
1. Has anyone used method combinations other than the standard one ?
In particular any of those in "7.6.6.4 Built-in Method Combination Types" ?
2. Have you ever defined your own method combinations using
DEFINE-METHOD-COMBINATION ? If yes , did they take a lambda list ?
I mean the part in the syntax define-method-combination name lambda-list .
Do you happen to know whether any Lisp dialects leading up to Common Lisp had
object systems providing facilities similar to the above ?
There is an implementation of the Eiffel language design by contract as
a custom method combination. I don't think it's ever been used in anger
for a large system but it shows the flexibility.
There is where ?
Spiros Bousbouras <spibou@gmail.com> wrote:
Can you say more like what you were writing ? Because personally I can't think
of an occasion where I would find the operator method combinations useful but
I wouldn't be able to achieve the same functionality in some other way , likely
a more straightforward one.
For instance logging: want all methods on the log object to run, use progn and they will now all run. Or checking some object allows some action:
want all methods on it to return true, use and, this will then happen.
Do you mean :around methods ? These only take :most-specific-first or :most-specific-last arguments. You actually had a use for those ?
No I mean wrapping methods, which run outside around methods and in most specific last order. wrapping method means that class near top of inheritance graph can establish dynamic state around all other methods and know that it will not be overridden, or can establish default values for arguments:
(defvar *blob-cache-default* t)
(defgeneric blob (x &key cache)
(:method-combination wrapping-standard)
(:method :wrapping (x &key (cache *blob-cache-default*))
(call-next-method x :cache cache)))
now no other methods need to worry about the default for the cache
argument: it is defined in one place, not many.
Is worth pointing out that is easy to experimentally check that method
combinations such as above have no run-time overhead.
I would imagine that depends on the implementation.
Any PCL-derived implementation I think, unless they have gone out of their way to break things. Perhaps there are non-PCL-derived implementations.
As other person says, if you find method combinations unuseful is perhaps because you have spent too much time with the many primitive languages
where you have to manually construct them by establishing explicit protocol for methods 'this method should do its check and if it succeeds it must invoke the next method and return its result otherwise return false' is the sort of awful manual errorful pain you must do in Python say to implement
and method combination.
Where does this wrapping-standard method combination come from ? It's not part of the CL standard.
SoC ?
I have an example in Clon (clon/core/src/output/sheet.lisp). In
general, yes, I find the operator-based standard method
combinations quite usefull (although preferably extended with
:before / :after / and :around).
Operator method combinations only support :around methods.
More recently, I developed a pretty elaborate (but it's only 10 lines
long, so in fact it's pretty straightforward ;-)) method combination
for Declt 4, in the documentation rendering code. I don't have the
time to explain it here right now, but you can find it in
declt/core/src/doc/cod.lisp currently. Trust me on this, thanks to
that, the documentation code became so much cleaner than in version
3...
Where do I find this code ? It doesn't seem to exist under www.didierverna.info .
Separation of Concerns (orthogonality if you prefer). The idea being
that method combinations allow you to remove whatever dispatch-related
code there was in your methods before. Hence, what you put in your
methods is strictly focused on the job of the method itself, and
nothing else. The benefits in term of software engineering are
obvious: if you ever need to add or remove methods, you don't have to
modify the other ones to figure out who calls who, if you need to
change the ordering, there's a unique and central place to update (the
combination), etc., etc.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:26:36 |
| Calls: | 6,910 |
| Files: | 12,376 |
| Messages: | 5,429,210 |