www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - import RFC

reply kris <foo bar.com> writes:
Unfortunately, the conversion to pdf lost some of the formatting.  Take 
it for what it is:

http://larsivi.net/files/ImportIssues.pdf
Jul 11 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
kris wrote:
 Unfortunately, the conversion to pdf lost some of the formatting.  Take
 it for what it is:
 
 http://larsivi.net/files/ImportIssues.pdf

Has someone set up a poll already somewhere? I suppose a majority of D users are with you. FQS is definitely not the way to go - hey, even Eclipse automatically converts those FQS:s to imports in order to avoid confusion. Still this 'safe import' -approach has some drawbacks. At first I thought about something like implicit "static" private import of modules within the same package, but could it possibly cause naming conflicts? AFAIK the modules have a 1-to-1 correspondence with physical file names and it's impossible to have 2+ files with exactly the same file path and file name on many file systems. I have a framework of ~100 stub/skeleton classes (no implementation, just method & class names). These classes are almost all in different modules because the implementation details need to be private for real. One problem is that doing import in the 'safe' way results in lot of redundant code: import path.to.foo as foo; import path.to.bar as bar; auto a = new foo.Foo(1, 2) auto b = new bar.Bar(3, 4); bar.Bar.doStaticMethod(); //...and so on It should be somehow possible to import these symbols to the "top level" of the local namespace - but prevent the compiler from chaining these imports further(module xyz gets access to symbols in foo by importing bar when bar imports foo). I really haven't quite even started the project yet and by judging all the proposed import systems the situation looks a bit bleak. I would rather code all this stuff in Java. Perhaps my solution would be to allow both unsafe and safe imports, but prevent the compiler from chaining the imports. The default behaviour would be to import to the "top level" of the namespace, to avoid conflicts the alternative syntax would be to support this proposed syntax (import a.b.c.foo as foo): module foo: class A {} module bar: class A {} class B {} module xyz: import foo; public import bar as bar; // allows chaining class C {} auto a = new A(); // A from foo auto b = new bar.A(); // A from bar auto c = new bar.B(); // B from bar //auto d = new B(); // not allowed module abc: import xyz; auto a = new C(); // C from xyz auto b = new A(); // not allowed auto c = new bar.B(); // B from bar What do you think? -- Jari-Matti
Jul 11 2006
next sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <e90efu$2c2f$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
kris wrote:
 Unfortunately, the conversion to pdf lost some of the formatting.  Take
 it for what it is:
 
 http://larsivi.net/files/ImportIssues.pdf

Has someone set up a poll already somewhere?

Yes, they have. http://www.dsource.org/forums/viewtopic.php?t=1658 jcc7
Jul 11 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Jari-Matti Mäkelä wrote:
 One problem is that doing import in the 'safe' way results in lot of
 redundant code:
 
 import path.to.foo as foo;
 import path.to.bar as bar;
 
 auto a = new foo.Foo(1, 2)
 auto b = new bar.Bar(3, 4);
 bar.Bar.doStaticMethod();
 //...and so on
 
 It should be somehow possible to import these symbols to the "top level"
 of the local namespace - but prevent the compiler from chaining these
 imports further(module xyz gets access to symbols in foo by importing
 bar when bar imports foo).

I think the correct approach here would be to make all imports private and hope that the lookup mechanism changes so private symbols are truly invisible across module boundaries. This came up briefly in the Mother Of All Threads above, but wasn't pursued since the import issue seemed perhaps more important. But perhaps once the import syntax issue has been resolved, the topic could be revisited. At the very least, I'm hoping that Walter will be able to find out why the C++ lookup rules (which D's are based on) were done the way they are, and whether any of the factors have any bearing on D. As for the topic at hand, I feel that: * "static import" is better than what we have now, but I'm not terribly keen on the need for an additional alias line to avoid FQS names (which I expect to commonly be quite long). I know it's just an additional line of code, but this is a case where the need for an alias line may relegate the entire feature to the realm of the Exceedingly Careful. * Some variation on the "as" syntax appears to be the best means of achieving readability, easing maintenance, and encouraging the use of what I feel is a good programming practice. I also believe little things like this are crucial in deciding whether a particular feature or technique achieves common use. * Selective import at the symbol level would be a terrific perk, but if worse came to worse I could live with some form of qualified import plus alias *assuming this technique would not cause "multiply defined symbol" errors*. I'm quite certain I've had this problem in the past with the import/alias combination, and if this was simply a bug or if I was doing something wrong then I'd like to know :-) Exposing only specific symbols of an imported module isn't terribly needful for user-level applications, but it is extremely useful for library design where any public symbol exposed by a module is considered a part of that module's interface. * If some change is to occur, I would really prefer it be as aesthetically pleasing as possible. Arcane syntax would risk relegating this feature to the dustbin for many programmers, and this is something I believe should be common practice for any serious project. * Any well-designed implementation is likely to see a lot of use. The concept has nearly universal support in discussion (only the details seemed to be at issue), and I know that Kris, myself, and many others would encourage the use of such a technique through example in our own library code and in any associated coding guidelines. I'm not sure that this in itself is a panacea as your comments demonstrate, Jari, but I believe it is a good step towards supporting the development of large projects in D. Sean
Jul 11 2006
next sibling parent "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Sean Kelly" <sean f4.ca> wrote:
 As for the topic at hand, I feel that:

 * "static import" is better than what we have now, but I'm not terribly 
 keen on the need for an additional alias line to avoid FQS names (which I 
 expect to commonly be quite long).  I know it's just an additional line of 
 code, but this is a case where the need for an alias line may relegate the 
 entire feature to the realm of the Exceedingly Careful.

 * Some variation on the "as" syntax appears to be the best means of 
 achieving readability, easing maintenance, and encouraging the use of what 
 I feel is a good programming practice.  I also believe little things like 
 this are crucial in deciding whether a particular feature or technique 
 achieves common use.

I think the best keyword to use is "alias". It's already used for the same purpose, so would not be overloaded to mean something completely other. As for "as", "alias" in my opinion would be easier to remember, since we're using it already to alias the names. So, for example, say that module.name.whatever contains a function foobar. Now (fuller in the "the point of selective importing" thread): static import module.name.whatever alias mnw; allows to call foobar through module.name.whatever.foobar or mnw.foobar, meaning foobar could not clash with anything imported from another module, say if we import another.module, also defining a function foobar.
Jul 11 2006
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Sean Kelly wrote:
 Jari-Matti Mäkelä wrote:

Thanks for the reply. First of all I didn't mean to start this thread redundantly all over again. I just happened to miss that huge thread after reading other 500+ posts. Uh, I was gone only about a week and things have really gone forward - the general point of interest has focused on more relevant things. I'm eagerly waiting for 1.0 now.
 This came up briefly in the Mother
 Of All Threads above, but wasn't pursued since the import issue seemed
 perhaps more important.  But perhaps once the import syntax issue has
 been resolved, the topic could be revisited.  At the very least, I'm
 hoping that Walter will be able to find out why the C++ lookup rules
 (which D's are based on) were done the way they are, and whether any of
 the factors have any bearing on D.

Correct me if I'm wrong, but I thought all these things around import are related. I've read now ~ 25% of the recent posts about imports and it seems that when one talks about functionality, the other has selected style of syntax as the starting point. I'm personally more interested in language functionality and think we should find a consensus on functional guidelines before going into syntax details (e.g. whether 'as' is a good keyword or not). One of the core issues IMO is to know, whether modules 'inherit' the namespace of the 'grandparent' module by default (or should it be made optional) and how do we access these symbols and what are the FQS rules on a general level.
 * Selective import at the symbol level would be a terrific perk, but if
 worse came to worse I could live with some form of qualified import plus
 alias *assuming this technique would not cause "multiply defined symbol"
 errors*.  I'm quite certain I've had this problem in the past with the
 import/alias combination, and if this was simply a bug or if I was doing
 something wrong then I'd like to know :-)

If you mean "conflicts with %s at %s", it's pretty normal with unsafe imports when one does not use FQS names. Having a broken handling of protection attributes doesn't help either, but that has been discussed elsewhere.
 Exposing only specific
 symbols of an imported module isn't terribly needful for user-level
 applications, but it is extremely useful for library design where any
 public symbol exposed by a module is considered a part of that module's
 interface.

It should be enough the control the accessibility with protection attributes. Importing individual module members is a bit overkill. I don't have any previous experience on that matter (Java has only one public top-level "module" member and no templates nor delegates), but I suppose it could possible cause some missing dependencies.
 * Any well-designed implementation is likely to see a lot of use.  The
 concept has nearly universal support in discussion (only the details
 seemed to be at issue), and I know that Kris, myself, and many others
 would encourage the use of such a technique through example in our own
 library code and in any associated coding guidelines.  I'm not sure that
 this in itself is a panacea as your comments demonstrate, Jari, but I
 believe it is a good step towards supporting the development of large
 projects in D.

Yes, I agree. As a said before, we're mixing apples and oranges here. For me (and I think many pragmatic applications programmers, not compiler experts) the most important syntactical aspect is to have a consistent, elegant and easy to parse language. It should be as simple as possible, but also extensible. Functionally wise there should be consensus on what things should be allowed and what things are illegal by design. -- Jari-Matti
Jul 11 2006
parent Sean Kelly <sean f4.ca> writes:
Jari-Matti Mäkelä wrote:
 Sean Kelly wrote:

 Jari-Matti Mäkelä wrote:

 This came up briefly in the Mother
 Of All Threads above, but wasn't pursued since the import issue seemed
 perhaps more important.  But perhaps once the import syntax issue has
 been resolved, the topic could be revisited.  At the very least, I'm
 hoping that Walter will be able to find out why the C++ lookup rules
 (which D's are based on) were done the way they are, and whether any of
 the factors have any bearing on D.

Correct me if I'm wrong, but I thought all these things around import are related. I've read now ~ 25% of the recent posts about imports and it seems that when one talks about functionality, the other has selected style of syntax as the starting point. I'm personally more interested in language functionality and think we should find a consensus on functional guidelines before going into syntax details (e.g. whether 'as' is a good keyword or not).

I think part of this simply stems from the fact that most user-driven changes to D originate from proposals rather than progressive design discussion. So it's not uncommon for suggested syntax and such to be a part of the proposal, particularly in a case like this where aesthetics are an important aspect of the feature. But I agree that this approach seems to result in unfocused discussion.
 One of the core issues IMO is to know, whether modules 'inherit' the
 namespace of the 'grandparent' module by default (or should it be made
 optional) and how do we access these symbols and what are the FQS rules
 on a general level.

Definately.
 Exposing only specific
 symbols of an imported module isn't terribly needful for user-level
 applications, but it is extremely useful for library design where any
 public symbol exposed by a module is considered a part of that module's
 interface.

It should be enough the control the accessibility with protection attributes. Importing individual module members is a bit overkill. I don't have any previous experience on that matter (Java has only one public top-level "module" member and no templates nor delegates), but I suppose it could possible cause some missing dependencies.

So long as there is a way to expose only specific symbols imported from a parent module and to avoid collisions if the user imports both the parent and importing modules then I'll be happy. From my experimentation there's currently no way to do this now.
 * Any well-designed implementation is likely to see a lot of use.  The
 concept has nearly universal support in discussion (only the details
 seemed to be at issue), and I know that Kris, myself, and many others
 would encourage the use of such a technique through example in our own
 library code and in any associated coding guidelines.  I'm not sure that
 this in itself is a panacea as your comments demonstrate, Jari, but I
 believe it is a good step towards supporting the development of large
 projects in D.

Yes, I agree. As a said before, we're mixing apples and oranges here. For me (and I think many pragmatic applications programmers, not compiler experts) the most important syntactical aspect is to have a consistent, elegant and easy to parse language. It should be as simple as possible, but also extensible. Functionally wise there should be consensus on what things should be allowed and what things are illegal by design.

Agreed. Sean
Jul 12 2006