It's case 2. In a single whizbang library I have three modules like so:
whizbang.rs
import whiz::*;
import bang::*;
export whiz1, whiz2;
export bang1;
whiz.rs:
fn whiz1() {}
fn whiz2() {}
bang.rs:
fn bang1() {}
Then in an exe I want to be able to use whizbang items without worry about
about the physical organization of the component modules. For example, I wanted
to be able to do something like:
client.rs
import whizbang;
fn foo()
{
whizbang::bang1();
}
Which sounds like it is supposed to work.
-- Jesse
On Jul 2, 2012, at 12:13 PM, Graydon Hoare wrote:
> On 02/07/2012 11:59 AM, Brian Anderson wrote:
>> On 07/01/2012 03:47 PM, Jesse Jones wrote:
>>> I'm confused about how I can structure libraries. Let's say I have a
>>> whizbang library. It's complex enough that I want whiz and bang
>>> submodules, but that's just an implementation detail: I'd like clients
>>> of the libraries to use the public API with just an `import
>>> whizbang;`. I had thought something like the following would work:
>>>
>>> whizbang.rs
>>> import whiz::*;
>>> import bang::*;
>>>
>>> export whiz1, whiz2;
>>> export bang1;
>>>
>>> whiz.rs:
>>> fn whiz1() {}
>>> fn whiz2() {}
>>>
>>> bang.rs:
>>> fn bang1() {}
>>>
>>> And it does work…but only within the whizbang project. whiz.rs, for
>>> example, can use bang1 without even doing an import. But external
>>> libraries have to do whizbang::whiz::whiz1.
>>>
>>
>> I would expect this to work as written. core.rs does similar things to
>> expose option::some, none, etc. Perhaps it's because of a resolve bug.
>> core doesn't use `import::*` for example, so maybe reexporting an import
>> star is funky.
>
> I can see two possibilities:
>
> #1: The bug report is ambiguous. It's not clear whether the reporter
> wants to be able, in external libraries, to write:
>
> import whizbang; // import from where?
> bang1(); // import didn't mention this
>
> or something else. That example, as written, won't work for 2
> reasons: 'import' and 'use' are different directives, and anyway
> import only imports the name 'whizbang', not any of the sub-names.
> I _would_ expect the following example to work:
>
> use whizbang; // link in the library
> whizbang::bang1(); // access through the linked name
>
> #2: There might be a bug in resolve concerning the import/export
> interaction. This is ... if true, one of a long set of bugs
> that we have so many of on resolve that patrick is presently
> rewriting that module of the compiler from scratch (about to
> merge probably this week) to approach the resolve algorithm
> in an entirely different fashion.
>
> If it's just #1, try the other example and see how it fares. If it's #2, I'd
> suggest waiting until the resolve rewrite lands and then trying again to see
> if the bug goes away. There were a ton of weird corner cases surrounding
> globbed imports in the old code. We're pretty convinced it wasn't even
> well-defined (global order-sensitivity, infinite loop possibilities, all
> sorts of awfulness).
>
> -Graydon
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
