> Samuele Pedroni <pedronis@bluewin.ch>: > > > The problem is that normally modules are uniquely globally identified > > singletons, but the very notion of parametrization implies instantiation and > > that breaks the singleton part. to makes things clearer > Python already has things you can instantiate -- they're > called classes! Python already has things you can parametrize -- they're called classes! > Seems to me if you want instantiation, you should be using > a class, not a module. Seems to me if you want parametrization, you should be using a class, not a module. Maybe. [ what is sometimes called a "unit" that means a parametrizable and instatiable module can be a useful generic-programming construct. ] the underlying questions is how much cap-Python programming can be like/we want it like current Python programming? for example concretely, module and imports are often used to access "program-wide" factories. Do we want cap-confined client code to be rewritten in order to pass the factories or single factory-constructed objects otherwise: [Zooko] >So one design for cap-Python might say that only safe modules can be imported by >cap-Python code. Every unsafe privilege would have to be granted by using >references (passed as arguments, assigned to variables, etc.). No authority >would ever be made available to capability-secured code through "import". or not. There are trade-offs in terms of necessary semantics changes/complexity vs. language overall feeling preservation and legacy code reuse and adaptation.
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