digitalmars.D - [suggestion] alternate import syntax [Walter]
- TechnoZeus (46/46) Apr 30 2005 I've been thinking, it would be useful to be able to specify more inform...
- TechnoZeus (8/27) Apr 30 2005 or...
- Walter (10/11) Apr 30 2005 statically loaded, under separate namespaces.
- TechnoZeus (6/17) May 01 2005 Thanks, Walter.
- jpoirier (28/86) Apr 30 2005 Hi Walter,
- jpoirier (7/116) Apr 30 2005 My apologies for the mixup as to whom my reply was directed to, and henc...
- TechnoZeus (4/135) May 01 2005 It's okay... mixups happen. :)
I've been thinking, it would be useful to be able to specify more information about an import, for cases where the filename and the module name don't match, or for cases where it is desireable to place a module into an alternative namespace. Here's the current syntax... import ModuleNameList ; where ModuleNameList is one of... ModuleName or... ModuleName , ModuleNameList Now, for the alternate syntax... import ModuleIdentificationList ; where ModuleIdentificationList is one of... ModuleIdentification or... ModuleIdentification , ModuleIdentificationList and ModuleIdentification is one of... ModuleName or... ModuleName from `ModuleFileName` or... `ModuleFileName` as NameSpace or... ModuleName from `ModuleFileName` as NameSpace Here's how it would work. If the namespace is omited, then the module name would imply the namespace. If the filename is omited then the module name would imply the filename (as it does now) which could be overridden by compiler flags. If the module name or file name is omited, then the namespace would imply them as needed. If both the filename and module name are specified, and a module name is given for the module inside of the file, but it doesn't match the specified module name, then the compiler would report an error. The specified namespace would be used to fully qualify imported items regardless of the filename or module name. This would also allow more than one instance of the same module to be statically loaded, under separate namespaces. For example... import mystuff from `myfile`, morestuff, morestuff as even.more.stuff; This would import the module file "myfile" under the namespace "mystuff" provided it doesn't internally identify itself as a module other than "mystuff", and would import the module file "morestuff" into the namespace "morestuff", and a second copy of "morestuff" into the namespace "even.more.stuff". This would allow programmers better control "while they are programming" over what happens at compile time, rather than having to rely on compiler flags and such to make sure that everything goes as planned. Afterall, the more of the plan we can specify "in the code" the less can go wrong later. TZ
Apr 30 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> ----- Original Message ----- From: TechnoZeus Newsgroups: digitalmars.D Sent: Saturday, April 30, 2005 3:26 PM Subject: [suggestion] alternate import syntax [Walter]*snip*Now, for the alternate syntax... import ModuleIdentificationList ; where ModuleIdentificationList is one of... ModuleIdentification or... ModuleIdentification , ModuleIdentificationList and ModuleIdentification is one of... ModuleName or... ModuleName from `ModuleFileName` or... `ModuleFileName` as NameSpace or... ModuleName from `ModuleFileName` as NameSpaceor... ModuleName as NameSpace I forgot to include that one. It would basically be identical to what we have now, except that the module would be specified into the specified namespace rather than a namespace derived from the module name. TZ
Apr 30 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message news:d50q0p$15m6$1 digitaldaemon.com...This would also allow more than one instance of the same module to bestatically loaded, under separate namespaces. You can do that now, just by putting the import inside the namespace you want it to be in, like: struct S { import foo; } S.foo.bar ...
Apr 30 2005
"Walter" <newshound digitalmars.com> wrote in message news:d50sq2$182q$1 digitaldaemon.com..."TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message news:d50q0p$15m6$1 digitaldaemon.com...Thanks, Walter. I hadn't thought of that, but yes that should serve part of the same purpose. Still though, I hope you will consider my proposed syntax additions for some future version of D, both for a more direct way of importing into a namespace, and because of the other advantages I indicated earlier. TZThis would also allow more than one instance of the same module to bestatically loaded, under separate namespaces. You can do that now, just by putting the import inside the namespace you want it to be in, like: struct S { import foo; } S.foo.bar ...
May 01 2005
Hi Walter, Python imports modules similar to what you've proposed, see the examples below. Over viewing Python's model may save you some time if you do decide to make changes. import MyModule MyModule is bound to the variable name MyModule in the current scope of the module object import MyModule [as varname][,...] varname is bound to the module object MyModule, therefore, varname serves more or less as an alias to MyModule There's also a "from" statement that gives even finer granularity as to the attributes being imported: from MyModule import attrname [as varname] [,...] from MyModule import attrname from MyModule import * There are certain qualifications that may or may not need to be used as based on the type of the import, e.g., import "MyModule" would require the use of "MyModule.myattrib" for attribute use. Similar to "import MyModule as myvar" would require "myvar.myattrib". Using "from MyModule import *" binds _all_ attributes globally in the importing module, therefore, there would be no qualifier required to use an attribute. Of course I've greatly simplified things... but I it's useful anyway. Joe - "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message news:d50q0p$15m6$1 digitaldaemon.com...I've been thinking, it would be useful to be able to specify more information about an import, for cases where the filename and the module name don't match, or for cases where it is desireable to place a module into an alternative namespace. Here's the current syntax... import ModuleNameList ; where ModuleNameList is one of... ModuleName or... ModuleName , ModuleNameList Now, for the alternate syntax... import ModuleIdentificationList ; where ModuleIdentificationList is one of... ModuleIdentification or... ModuleIdentification , ModuleIdentificationList and ModuleIdentification is one of... ModuleName or... ModuleName from `ModuleFileName` or... `ModuleFileName` as NameSpace or... ModuleName from `ModuleFileName` as NameSpace Here's how it would work. If the namespace is omited, then the module name would imply the namespace. If the filename is omited then the module name would imply the filename (as it does now) which could be overridden by compiler flags. If the module name or file name is omited, then the namespace would imply them as needed. If both the filename and module name are specified, and a module name is given for the module inside of the file, but it doesn't match the specified module name, then the compiler would report an error. The specified namespace would be used to fully qualify imported items regardless of the filename or module name. This would also allow more than one instance of the same module to be statically loaded, under separate namespaces. For example... import mystuff from `myfile`, morestuff, morestuff as even.more.stuff; This would import the module file "myfile" under the namespace "mystuff" provided it doesn't internally identify itself as a module other than "mystuff", and would import the module file "morestuff" into the namespace "morestuff", and a second copy of "morestuff" into the namespace "even.more.stuff". This would allow programmers better control "while they are programming" over what happens at compile time, rather than having to rely on compiler flags and such to make sure that everything goes as planned. Afterall, the more of the plan we can specify "in the code" the less can go wrong later. TZ
Apr 30 2005
My apologies for the mixup as to whom my reply was directed to, and hence its structure as well. I made the mistake of trying to read, post a reply, and watch my four year old all at the same time. :-) -Joe "jpoirier" <aj.po charter.net> wrote in message news:d50uh5$19fv$1 digitaldaemon.com...Hi Walter, Python imports modules similar to what you've proposed, see the examples below. Over viewing Python's model may save you some time if you do decide to make changes. import MyModule MyModule is bound to the variable name MyModule in the current scope of the module object import MyModule [as varname][,...] varname is bound to the module object MyModule, therefore, varname serves more or less as an alias to MyModule There's also a "from" statement that gives even finer granularity as to the attributes being imported: from MyModule import attrname [as varname] [,...] from MyModule import attrname from MyModule import * There are certain qualifications that may or may not need to be used as based on the type of the import, e.g., import "MyModule" would require the use of "MyModule.myattrib" for attribute use. Similar to "import MyModule as myvar" would require "myvar.myattrib". Using "from MyModule import *" binds _all_ attributes globally in the importing module, therefore, there would be no qualifier required to use an attribute. Of course I've greatly simplified things... but I it's useful anyway. Joe - "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message news:d50q0p$15m6$1 digitaldaemon.com...I've been thinking, it would be useful to be able to specify more information about an import, for cases where the filename and the module name don't match, or for cases where it is desireable to place a module into an alternative namespace. Here's the current syntax... import ModuleNameList ; where ModuleNameList is one of... ModuleName or... ModuleName , ModuleNameList Now, for the alternate syntax... import ModuleIdentificationList ; where ModuleIdentificationList is one of... ModuleIdentification or... ModuleIdentification , ModuleIdentificationList and ModuleIdentification is one of... ModuleName or... ModuleName from `ModuleFileName` or... `ModuleFileName` as NameSpace or... ModuleName from `ModuleFileName` as NameSpace Here's how it would work. If the namespace is omited, then the module name would imply the namespace. If the filename is omited then the module name would imply the filename (as it does now) which could be overridden by compiler flags. If the module name or file name is omited, then the namespace would imply them as needed. If both the filename and module name are specified, and a module name is given for the module inside of the file, but it doesn't match the specified module name, then the compiler would report an error. The specified namespace would be used to fully qualify imported items regardless of the filename or module name. This would also allow more than one instance of the same module to be statically loaded, under separate namespaces. For example... import mystuff from `myfile`, morestuff, morestuff as even.more.stuff; This would import the module file "myfile" under the namespace "mystuff" provided it doesn't internally identify itself as a module other than "mystuff", and would import the module file "morestuff" into the namespace "morestuff", and a second copy of "morestuff" into the namespace "even.more.stuff". This would allow programmers better control "while they are programming" over what happens at compile time, rather than having to rely on compiler flags and such to make sure that everything goes as planned. Afterall, the more of the plan we can specify "in the code" the less can go wrong later. TZ
Apr 30 2005
It's okay... mixups happen. :) Thanks for pointing that out. Actually, I do hope Walter sees it. This is much less important than fixing all the bugs, which he's currently concentrating on... but still would make a nice addition, in the long run. TZ "jpoirier" <aj.po charter.net> wrote in message news:d512nb$1d7f$1 digitaldaemon.com...My apologies for the mixup as to whom my reply was directed to, and hence its structure as well. I made the mistake of trying to read, post a reply, and watch my four year old all at the same time. :-) -Joe "jpoirier" <aj.po charter.net> wrote in message news:d50uh5$19fv$1 digitaldaemon.com...Hi Walter, Python imports modules similar to what you've proposed, see the examples below. Over viewing Python's model may save you some time if you do decide to make changes. import MyModule MyModule is bound to the variable name MyModule in the current scope of the module object import MyModule [as varname][,...] varname is bound to the module object MyModule, therefore, varname serves more or less as an alias to MyModule There's also a "from" statement that gives even finer granularity as to the attributes being imported: from MyModule import attrname [as varname] [,...] from MyModule import attrname from MyModule import * There are certain qualifications that may or may not need to be used as based on the type of the import, e.g., import "MyModule" would require the use of "MyModule.myattrib" for attribute use. Similar to "import MyModule as myvar" would require "myvar.myattrib". Using "from MyModule import *" binds _all_ attributes globally in the importing module, therefore, there would be no qualifier required to use an attribute. Of course I've greatly simplified things... but I it's useful anyway. Joe - "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message news:d50q0p$15m6$1 digitaldaemon.com...I've been thinking, it would be useful to be able to specify more information about an import, for cases where the filename and the module name don't match, or for cases where it is desireable to place a module into an alternative namespace. Here's the current syntax... import ModuleNameList ; where ModuleNameList is one of... ModuleName or... ModuleName , ModuleNameList Now, for the alternate syntax... import ModuleIdentificationList ; where ModuleIdentificationList is one of... ModuleIdentification or... ModuleIdentification , ModuleIdentificationList and ModuleIdentification is one of... ModuleName or... ModuleName from `ModuleFileName` or... `ModuleFileName` as NameSpace or... ModuleName from `ModuleFileName` as NameSpace Here's how it would work. If the namespace is omited, then the module name would imply the namespace. If the filename is omited then the module name would imply the filename (as it does now) which could be overridden by compiler flags. If the module name or file name is omited, then the namespace would imply them as needed. If both the filename and module name are specified, and a module name is given for the module inside of the file, but it doesn't match the specified module name, then the compiler would report an error. The specified namespace would be used to fully qualify imported items regardless of the filename or module name. This would also allow more than one instance of the same module to be statically loaded, under separate namespaces. For example... import mystuff from `myfile`, morestuff, morestuff as even.more.stuff; This would import the module file "myfile" under the namespace "mystuff" provided it doesn't internally identify itself as a module other than "mystuff", and would import the module file "morestuff" into the namespace "morestuff", and a second copy of "morestuff" into the namespace "even.more.stuff". This would allow programmers better control "while they are programming" over what happens at compile time, rather than having to rely on compiler flags and such to make sure that everything goes as planned. Afterall, the more of the plan we can specify "in the code" the less can go wrong later. TZ
May 01 2005