[Greg Ewing] >So far no-one has addressed the other importing problem >I mentioned, which is how to ensure that the relevant >modules get imported *at all*. We were busy agreeing on the basic stuff :(. > >Currently in Python, a module gets imported because >some other module needs to use a name from it. If no >other module needs to do so, the module is not needed. > >But with generic functions, this will no longer be >true. It will be possible for a module to be needed >by the system as a whole, yet no other module knows >that it is needed! What a dramatic personification <wink>! Yes it's a real bookkeeping problem. Sidenote: Common Lisp systems deliver programs as whole system images, and one often uses an image to store development snapshots. So it's not really an issue for the program at startup. Libraries nevertheless should come with "scripts" that assure that all their relevant parts are loaded. OTOH as long as a programmer immediately loads his definitions/redefinitions and use the image for snapshots he can forget about the issue. But even he should still care about being able to reload/reconstruct the system from the source files and from scratch. So in the end the problem is not completely only a Python problem. At the moment the following bookkeeping rules come to my mind to address the issue: - a module in a library that exposes a generic function defined by the library (defgeneric) should make sure that all the definitions of methods in the library are already added to the generic function once the generic function is exposed. - a module in a library that exposes classes for which it adds specialized methods to a generic function defined in and imported from another library, should assure that once the class instances can be obtained the specialized versions are already added. It seems to me that this should cover most of the sane cases. Recap/ Issues' orthogonal and not so orthogonal decomposition: - Support for multimethods can be written in (pure) Python today, at this level the question is whether to have such support in the std lib or not; - if my understanding is correct Dave Abrahams wants multimethod dispatch as the moral equivalent of static overloading, for that use gf-method definitions would in most cases be just in one place (especially if what we are "overloading" is a normal class method) and the generic function is expected to be used just as a normal function; - nice to have: dispatch on protocols/categories; this intersect a well-known everrecurrent issue; - how much should multimethods become part of the language? are they a useful addition? what about newbies? can multimethods be made play nice with the rest of the language (especially with single dispatch and normal class methods [*])? will they eventually deserve syntax sugar? are they a Py3K thing? and-who-put-that-multimethods'-evangelist-hat-on-my-head-?-[and-I-had not-much-time-(still-true)]-who?-and-now-I-will-hypnotize-you-all-and-everybody -should-buy-the-AMOP-ly y'rs - Samuele. [*] at the moment personally I see two possibilities: - have a type of generic function that can live inside a class (namespace) be able to redispatch (maybe just only if appropriately configurated) to superclasses' methods if no matching gf-method is found. [after, before, around methods would be difficult (impossible?) to implement with the right semantics] - redefine the normal dispatch rules (obj.meth(...)) in order to directly take care of generic functions inside classes [larger change]
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