Hi Neil,
On 1/7/2019 9:58 PM, Neil Van Dyke wrote:
George Neuner wrote on 1/7/19 4:49 PM:
Though I mostly agree with you, your "advice" does have its uses:
http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html
in particular see the sections on method combinations.
Thank you; I should've looked it up before incorrectly assuming that
you were talking about "advice" from some Lisps. I initially thought
the original question was getting at something like `defadvice`:
https://franz.com/support/documentation/10.1/doc/operators/excl/defadvice.htm
https://www.gnu.org/software/emacs/manual/html_node/elisp/Porting-old-advice.html
Part of what bugs me is violation of expectations: In Racket, when I
see or use a procedure reference in some code, I expect to get a
particular procedure implementation. (Given a straightforward
understanding of `#lang`, `require`, scoping, and syntax extension.)
If that's instead documented to be a generic, then my expectations
change to the implementation I receive (probably) performing an
analogous operation. (Actually, in Racket, I'd say generics and
classes are usually used only when overriding is definitely happening.)
I read the pages on defadvice / advise. It seems more general than
generic CL before/after/around methods in that [if I understand
correctly] advice can be applied to any function, not just one defined
by defgeneric.
But I'm not sure how your objection applies. Using generic functions
really is not different from using a class hierarchy - you expect the
different methods (classes) to be somehow related, but you accept that
each may do things differently. And you accept that a FOO in one
hierarchy may have no relationship whatsoever to a FOO in a different
hierarchy. So too, function FOO on one set of data types may have no
relation to function FOO on a different set of data types.
The before/after/around methods have no analogue in any object system I
am aware of. But they do have uses, and implementing their
functionality in the objects systems I do know requires instrumenting
every [participating] class in the hierarchy. The generic solution
saves duplicating a lot of [possibly error prone] type specific code.
YMMV,
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
