View previous topic :: View next topic |
Author |
Message |
Ligustah
Joined: 21 Oct 2007 Posts: 45 Location: Berlin, Germany
|
Posted: Tue Nov 06, 2007 6:38 am Post subject: import question / feature request |
|
|
Hi,
I have two litte questions:
1.
I was searching for something equivalent to this python statement:
Code: | import from <module name> * |
It's the syntax for selective imports (you could replace the * with comma separated names). Is there something like this already in MiniD? DI'd like to have something like this:
Code: | import <module name> : *; |
to import all of the functions of that module, as it could be very useful IMHO.
2.
I was woundering that:
is the same as: Code: | local function foo() {} |
I thought, that a language that aims to be embedded into other applications , would only create local functions, if you explicitly declared them, as i mostly declare functions to call them from the program later. Is there an important reason for the implicit "local" ?
Mfg Ligustah
Btw: "Mfg" is german. it's just one of my habits to write it and i just noticed it^^
http://dict.leo.org/ende?search=mit+freundlichen+gr%FC%DFen |
|
Back to top |
|
|
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Tue Nov 06, 2007 9:28 am Post subject: |
|
|
Quote: | It's the syntax for selective imports (you could replace the * with comma separated names). Is there something like this already in MiniD? DI'd like to have something like this: ... to import all of the functions of that module, as it could be very useful IMHO. |
There is explicit selective importing which looks like the corresponding D code:
Code: | import foo : one, two, three; |
The problem with the "import all" version is that in the above example, 'one', 'two', and 'three' are local variables. Locals are kept on the stack and the number of locals in a function is hard-coded. You can't create a bunch of locals for the "import all" statement, because you don't know how many symbols there will be in the imported module, and so you don't know how many locals to reserve (or what to call them). The alternative would be to import all the other module's symbols into this module's public namespace, but that would be just horrendous: you'd be able to access all of B's members through module A if A imports all of B's members. This could be solved with yet another level of namespacing (module namespace > import namespace > locals), but..
Quote: | I thought, that a language that aims to be embedded into other applications , would only create local functions, if you explicitly declared them, as i mostly declare functions to call them from the program later. Is there an important reason for the implicit "local" ? |
It's mostly out of good encapsulation design. You make global only the things you want to be accessible outside the module. It also makes more sense for nested functions to be local by default.
Quote: | Btw: "Mfg" is german. it's just one of my habits to write it and i just noticed it^^ |
I was wondering about that |
|
Back to top |
|
|
Ligustah
Joined: 21 Oct 2007 Posts: 45 Location: Berlin, Germany
|
Posted: Tue Nov 06, 2007 10:56 am Post subject: |
|
|
JarrettBillingsley wrote: | This could be solved with yet another level of namespacing (module namespace > import namespace > locals), but.. | But? Seriously, I don't really understand the problem Where is the big difference between importing three functions and importing maybe 7 or 8 available in the module?
Is that the reason:
JarrettBillingsley wrote: | the number of locals in a function is hard-coded | Does that mean, that there is only a limited number of locals "available"?
JarrettBillingsley wrote: | [...]. It also makes more sense for nested functions to be local by default. | Mh... I see. |
|
Back to top |
|
|
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Tue Nov 06, 2007 11:36 pm Post subject: |
|
|
Ligustah wrote: | JarrettBillingsley wrote: | This could be solved with yet another level of namespacing (module namespace > import namespace > locals), but.. | But? Seriously, I don't really understand the problem Where is the big difference between importing three functions and importing maybe 7 or 8 available in the module?
Is that the reason:
JarrettBillingsley wrote: | the number of locals in a function is hard-coded | Does that mean, that there is only a limited number of locals "available"? |
In a way, yes. When you do "import foo : a, b" it gets turned into "local a, b; import foo; a = foo.a; b = foo.b;". Those local declarations are in turn turned into what amounts to telling the compiler "reserve the next two available stack slots for some variables." The stack is really nothing but an array and locals are indices into that array. These indices are hard-coded at compile time, meaning you lose any information about which slot corresponds to which variable, and there's no way to "dynamically" allocate locals at runtime -- there are only as many locals in your function as you declare. This makes local accesses much more efficient (~4x faster than in Python), but is a bit less flexible.
This is one instance of where this system presents a problem. Another is when you try to use eval() or loadString(), you'll notice you can't access local variables in the enclosing scope, simply because that information no longer exists in the compiled version of the function. In Python this is easy and is no more complex than setting the parent environment of the eval'ed string to the enclosing function's environment, since locals are kept in a table. Keeping locals in a namespace is bad news for performance.
Solving the import issue by introducing another level of namespacing is tricky and inefficient, for the sake of doing something that's generally considered a bad use of import (ask most seasoned Python and Java users, and they'll tell you that * is bad). Not only does it make creating actual globals harder, but it adds another level of namespace lookup, making things just that much slower. If you reeeeeeeally want to import all the globals from another module into this one's namespace, you could do the following:
Code: | module foo;
import bar;
foreach(k, v; bar)
foo[k] = v; |
Basically, you copy all the globals from the other module into this module's global namespace. As long as you don't mind all those globals then becoming visible from foo, this works fine. |
|
Back to top |
|
|
Ligustah
Joined: 21 Oct 2007 Posts: 45 Location: Berlin, Germany
|
Posted: Thu Nov 08, 2007 2:16 pm Post subject: |
|
|
Ok. I understand. I think I have to adapt to the selective import then
Mfg Ligustah |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|