Zooko <zooko@zooko.com>: > So your proposal seems sort of like a kind of dynamic scoping for > modules Yes, it would be dynamic scoping of the import namespace. The reason I think it needs to be dynamic rather than lexical is that it isn't really objects or functions that we want to allow or deny capabilities to, it's *users* (for some suitably general notion of "user"). It may be okay for a particular method to do something when it's called by one user, but not another. The current method of controlling access to modules by overriding __import__ suffers from the problem that a given module can only have one __import__ hook at a time. There's no way for different users of the same module to have different importing abilities. >From what's been said about E, it seems that the solution there is to have instantiable modules (which means they're more like classes than modules, in Python terms) and to explicitly pass a lot of capabilities around. It seems to me that you'd end up with a lot of extra parameters to pass around in calls that way, and most of the time you'd just be passing on what had been passed to you -- hence my suggestion of dynamic scoping. But, not having studied any real E code, it may be that it doesn't turn out to be that bad in practice. Probably I shouldn't say any more until I know what I'm talking about... 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