Derek Parnell wrote:
> But currently it doesn't so does that mean currently DMD has this as a bug in it?
> 
> -----mod.d----
> private int foo;
> 
> ----test.d----
> import foo;
> 
> int x = foo.x; // access to a private member is allowed but it shouldn't be!!!

Yes, it's a bug.

Andrei Khropov wrote:
> Walter Bright wrote:
> 
>> There's another way - have a different kind of import declaration, say,
>> precede it with static:
>>
>> 	static import foo;
>>
>> which will make the symbols in foo available, but only if they are explicitly
>> qualified. Then one could access bar in foo by either:
>>
>> 	foo.bar();
>>
>> or:
>>
>> 	alias foo.bar bar;
>> 	bar();
>>
>> but not:
>>
>> 	bar();	// error, undefined symbol
>>
>> The advantage of this is it is a bit more flexible and more consistent with
>> the way the rest of D lookups work.
> 
> That's what I was talking about in
> http://www.digitalmars.com/d/archives/digitalmars/D/39348.html
> 
> Finally got a feedback from Walter :-)
> 
> Looking forward to see this in future releases.
> 
> "as" would be nice too but it's just syntactic sugar for fqn import + alias.
> 

Yes, but the syntactic sugar in this case might be a lot of bang for the buck if it's easy to implement along with allowing specific symbols to be imported. 'as' is much easier for newbies to D to grasp, turns 2 lines of code into one *and* makes it easier for maintainers to spot as they scan the imports (because aliases can and will be buried anywhere).

Dave wrote:
> Andrei Khropov wrote:
> 
>> Walter Bright wrote:
>>
>>> There's another way - have a different kind of import declaration, say,
>>> precede it with static:
>>>
>>>     static import foo;
>>>
>>> which will make the symbols in foo available, but only if they are explicitly
>>> qualified. Then one could access bar in foo by either:
>>>
>>>     foo.bar();
>>>
>>> or:
>>>
>>>     alias foo.bar bar;
>>>     bar();
>>>
>>> but not:
>>>
>>>     bar();    // error, undefined symbol
>>>
>>> The advantage of this is it is a bit more flexible and more consistent with
>>> the way the rest of D lookups work.
>>
>>
>> That's what I was talking about in
>> http://www.digitalmars.com/d/archives/digitalmars/D/39348.html
>>
>> Finally got a feedback from Walter :-)
>>
>> Looking forward to see this in future releases.
>>
>> "as" would be nice too but it's just syntactic sugar for fqn import + alias.
>>

hehe -- this wandering thread goes all over the ng. I'm moving this reply out of the gdc forum :)

the problem with the above is that the static-import would require all references to be "fully" prefixed. It looks ok on paper, but you'd end up with some very long names for references. It could be limited to use only the module name itself, and discard the path prefix e.g.

static import lib.text.locale.time;

auto time = new lib.text.locale.time.Time;  // where did the Time go?
auto time = new time.Time;                  // module name only
-----

but perhaps a better solution for this would arguably be

import lib.text.locale.time as quick;      // use a name of your choice

auto time = new quick.Time;
-----

Unfortunately this introduces a new keyword, "as".

There again, both these approaches are importing all symbols from the module; whereas the other proposal that most people seemed to like is an extension to /selectively/ import instead:

import lib.text.locale.time.Time;

auto time = new Time;
-----

This is clearly more explicit. There are benefits to both approaches, and while I'm in the latter camp as being the better overall solution, I'd really like to see both available :)

For example, as a library writer, I'm one of those who leans heavily toward grouping so-called free-functions into a namespace of their own. e.g. I'll use a struct to wrap a set of otherwise free-functions, just to give them a namespace. Some folk here would have a fit over that, but I do it to avoid the subtle namespace clashes that arise within other libraries. I'd be happy to drop that particular habit/workaround if the static-import were available (with the module-name-prefix only i.e. "new time.Time;"). This would work particularly well for nifti modules (Nifty Implicit Function Template Instantiation), and would avoid the one problem with using structs for namespace resolution -- which is that the linker cannot strip unused functions from a struct, so you may end up with some unused code in the executable. That kind of thing should really be avoided for nifti modules in particular.

But the selective import is still the more elegant solution, in my book. So if we had only one choice, you know where I'd be. If we can have both, then that would be even better. Too many choices is often a bad thing, but it this case each approach appears to have true merit, and its own place in creating robust and easy-to-manage code. If one or the other has a serious technical impediment, then that would have to be considered - obviously.


> Yes, but the syntactic sugar in this case might be a lot of bang for the buck if it's easy to implement along with allowing specific symbols to be imported. 'as' is much easier for newbies to D to grasp, turns 2 lines of code into one *and* makes it easier for maintainers to spot as they scan the imports (because aliases can and will be buried anywhere).

Yes, I fully agree. Alias can be useful, but it shouldn't be overused (like goto, I suppose; or champagne). It would be hard to keep track of imports that are aliased here and there, and the extra step involved (with adding an alias) would hardly be conducive to /encouraging/ namespace seperation. These might seem like small concerns to some, but within large bodies of code they really do make a notable difference.

kris wrote:
> the problem with the above is that the static-import would require all references to be "fully" prefixed. It looks ok on paper, but you'd end up with some very long names for references. It could be limited to use only the module name itself, and discard the path prefix e.g.
> 
> static import lib.text.locale.time;
> 
> auto time = new lib.text.locale.time.Time;  // where did the Time go? auto time = new time.Time;                  // module name only
> -----
> 
> but perhaps a better solution for this would arguably be
> 
> import lib.text.locale.time as quick;      // use a name of your choice
> 
> auto time = new quick.Time;
> -----
> 
> Unfortunately this introduces a new keyword, "as".
> 

Why not use "in"?

import lib.text.locale.time in quick;

To me, the meaning is quite clear, though it may not be as plain as "as". Maybe it helps to think of namespaces: "import 'lib.text.locale.time' into the 'quick' namespace".

Walter Bright wrote:
> Walter Bright wrote:
> 
>>>> What can also be done is extend the import declaration to allow the .'s to continue so that specific symbols can be imported.
>>>
>>>
>>> Now that would be great. I believe selective-importing (as an option) would be a boon in a number of ways ~ and would resolve this issue quite elegantly.
>>
>>
>> I like this one better, too.
> 
> 
> There's another way - have a different kind of import declaration, say, precede it with static:
> 
>     static import foo;
> 
> which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
> 
>     foo.bar();
> 
> or:
> 
>     alias foo.bar bar;
>     bar();
> 
> but not:
> 
>     bar();    // error, undefined symbol
> 
> The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.

I'm glad you liked my "static import" idea, but I have an additional suggestion.

Say we have the following module:

[foo.d]
module foo;

int bar;
char[] baz;
// ... and other names...

// EOF

I propose the following:

import foo;
    Does what it does now.

static import foo;
    Requires names in foo to be fully-qualified. Also, this should be implicitly private, so that modules that in turn import this one do not get the name "foo" inserted into their own namespaces.

static import foo with bar, baz;
    The names bar and baz can be accessed directly, any other names must be fully-qualified. (This reuses the 'with' keyword.) This should be synonymous with:

    static import foo;
    alias foo.bar bar;
    alias foo.baz baz;

    And it is much less verbose.

static import foo with bar as boo, baz;
    foo.bar can be accessed as boo, foo.baz as baz, and any other names in foo must be fully qualified. This should be the same as:

    static import foo;
    alias foo.bar boo;
    alias foo.baz baz;

    And (again) it is much less verbose. This has the disadvantage of requiring a new keyword. The word "alias" can be used in place of "as" to prevent this, though I don't think it reads as well.

import foo with bar, baz;
    This would import foo using the current rules, and promote bar and baz to first-class names, shadowing names imported from other modules. Any other names in foo would remain second-class names. Analogously to above, this is the same as:

    import foo;
    alias foo.bar bar;
    alias foo.baz baz;

    The syntax "import foo with bar as boo;" should obviously also be allowed.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Walter Bright wrote:
> Sean Kelly wrote:
>> Please see my post here:
> 
> Thanks for the reference. This rule, however, long predates Daveed's involvement with C++. I want to do a little more research on this.

By all means.  I'd love to hear the original reasoning--Daveed's statement was as close as I could get from a bit of googling.


Sean

kris wrote:

> 
> Unfortunately this introduces a new keyword, "as".

I don't think it's really a problem.

"as" syntax is very readable and is familiar to people who know Python.

-- 
AKhropov

On Sun, 09 Jul 2006 06:15:11 +1000, kris <foo@bar.com> wrote:


> but perhaps a better solution for this would arguably be
>
> import lib.text.locale.time as quick;      // use a name of your choice
>
> auto time = new quick.Time;
> -----
>
> Unfortunately this introduces a new keyword, "as".
>
> There again, both these approaches are importing all symbols from the module; whereas the other proposal that most people seemed to like is an extension to /selectively/ import instead:
>
> import lib.text.locale.time.Time;
>
> auto time = new Time;
> -----
>
> This is clearly more explicit. There are benefits to both approaches, and while I'm in the latter camp as being the better overall solution, I'd really like to see both available :)

Yes, both are needed to disabiguate members.

  import std.string.find;
  import std.regexp.find;

  find(text1, text2);  // Which 'find' do you want?

So we still need a way to do this. Maybe the 'as' keyword is not a bad idea here...


  import std.string.find;
  import std.regexp.find as re_find;

  re_find(text1, text2);

-- 
Derek Parnell
Melbourne, Australia

Sean Kelly wrote:
> Walter Bright wrote:
>> Derek Parnell wrote:
>>> I'm sorry Walter but I don't give newt's fart about C++. If I wanted to code under the rules of C++, I'd use C++. You have changed (improved) many of the C++ rules in D, so why not get this one right too?
>>
>> I agree that D exists to fix broken rules in C++, but we need to understand the rationale for why they are the way they are in C++, else we run the risk of making a severe error. I don't recall why the access rules are the way they are in C++, but I do know they weren't don't that way for backwards compatibility.
> 
> Please see my post here:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072
> 
> According to Daveed Vandevoorde:
> 
>    The fact that private members are inaccessible but not invisible
>    regularly surprises incidental programmers. Like macros, seemingly
>    unrelated declarations interfere with subsequent code. Unfortunately,
>    there are good reasons for this state of affair: Without it, private
>    out-of-class member declarations become impractical to parse in the
>    general case.
> 

Well, that clearly states that private members should not be invisible in C++, but I'm having trouble understanding why. He says "Without it, private out-of-class member declarations become impractical to parse in the general case." but I don't see how or why, anyone has an example or clarification?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> Walter Bright wrote:
>>>> What can also be done is extend the import declaration to allow the .'s to continue so that specific symbols can be imported.
>>>
>>> Now that would be great. I believe selective-importing (as an option) would be a boon in a number of ways ~ and would resolve this issue quite elegantly.
>>
>> I like this one better, too.
> 
> There's another way - have a different kind of import declaration, say, precede it with static:
> 
>     static import foo;
> 
> which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
> 
>     foo.bar();
> 
> or:
> 
>     alias foo.bar bar;
>     bar();
> 
> but not:
> 
>     bar();    // error, undefined symbol
> 
> The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.

Ah, the FQN import I (and others) have been waiting for. My comment:
http://www.digitalmars.com/d/archives/digitalmars/D/28423.html

[quote:]
PROPOSAL 1, FQN import:
Introduce a new statement, identical to import, :
  fqnimport <module>;
except that it only brings the <module> entity into scope. It's child
entities will have to be accessed trough the <module> entity (by FQN then).
The keyword for this statement could be "fqnimport", or perhaps a
shorter but still descriptive name like "mimport", "importm" (for import
module)? [Right now I'm favoring "importm" but am not decided;]
[/quote]

I must contested the proposed named by Walter. "static import" seems a pretty crappy name, there is nothing "static" about it. Do we have to recycle existing keywords? I'm not very much into this phobia of introducing new keywords. You didn't have a problem introducing "scope"... :P


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D