www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [suggestion] alternate import syntax [Walter]

reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
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
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
 ----- Original Message ----- 
 From: TechnoZeus
 Newsgroups: digitalmars.D
 Sent: Saturday, April 30, 2005 3:26 PM
 Subject: [suggestion] alternate import syntax [Walter]

 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

or... 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
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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 be

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
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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...
 This would also allow more than one instance of the same module to be

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 ...

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. TZ
May 01 2005
prev sibling parent reply "jpoirier" <aj.po charter.net> writes:
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
parent reply "jpoirier" <aj.po charter.net> writes:
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
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
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