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