Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
> As long as all the implementations have to be in one place,
> this is equivalent to
>
> def f(a):
> if belongstocategory(a, Cat1):
> ...
> elif belongstocategory(a, Cat2):
> ...
> elif belongstocategory(a, Cat3):
> ...
>
> so you're not gaining much from the new syntax.
Good point.
> > It might also be possible to modify a multimethod dynamically,
> > e.g. later one could write:
> >
> > def f4(a: Cat4):
> > ...code for Cat4...
> >
> > f.add(f4)
>
> This sort of scheme makes me uneasy, because it means that any module
> can change the behaviour of any call of f() in any other
> module.
True, but I don't think this is a problem in practice with CLOS is it?
I mean, you can currently do
import mod
mod.func = my_func # evil cackle!
but you don't.
> Currently, if you know the types involved in a method call,
> you can fairly easily track down in the source which piece of code
> will be called. With this sort of generic function, that will no
> longer be possible.
I would sincerely hope that any core implementation of such an idea
would be introspective enough to allow finding method implementations.
Obviously this would only work at run time, but it would be a help
(imagine running under pdb).
Cheers,
M.
--
Well, yes. I don't think I'd put something like "penchant for anal
play" and "able to wield a buttplug" in a CV unless it was relevant
to the gig being applied for...
-- Matt McLeod, alt.sysadmin.recovery
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4