> I mean, you can currently do > > import mod > > mod.func = my_func # evil cackle! That's my point -- f.add(method) is just like doing that. As with import *, no doubt the problems can be managed with appropriate discipline. But it's not clear to me what sort of discipline is needed. Suppose you have a module H defining class Hobbit, and a class E defining class Elf. Now you want to be able to add hobbits and elves, but you don't want to clutter up either H or E with stuff concerning the other one, so you put it in a third module M. Now suppose module X creates a Hobbit, and moule Y creates an Elf. In the course of processing, they both end up in module Z, which adds them together. It's not clear how you can tell, when looking at Z, where to look to find out what method will be called -- even if you know you're dealing with a Hobbit and an Elf. There's another problem, too -- who is responsible for *importing* module M? It's not E or H, neither of which knows about the other. It's not X, which only knows about Hobbits, or Y, which only knows about Elves. It's not Z, which doesn't know about either of them -- it just gets two things to add together. So, unless you arbitrarily insert an import of M into one of these modules, for no reason that's apparent from looking at that module -- M won't be imported at all, and the method it contains won't be added to the generic function. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
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