I understand that one could want flexibility and matching file with package
is not always optimal.
And it's not what I wanted to suggest in first place ;)
Let's clear one confusion first. When I said that I think *mod* and *extern
mod* are redundant I thought about using them in context of importing.
I think *mod *keyword used for creating modules (in sense of namespaces) is
fine and there is nothing wrong with it.
Now, I don't see big difference between *mod *and *extern mod, *because in
both cases intention is very similar: you want to signalize that required
modules are in external crate.
If I'll compile on of my modules into stand alone library and I'll put it
inside the project instead of module source files it should still work.
Because if it's technically possible, then why to complicate it?
I will try to clarify this with example. Current situation looks like this:
//-----------------> CUT HERE <--------------------
//------------------------- a.rs ---------------------------
mod b;
pub mod a_inner {
pub fn a_func() { ::b::b_inner::b_func(); }
}
fn main() {
a_inner::a_func();
}
//------------------------- b.rs ---------------------------
extern mod clib;
pub mod b_inner {
pub fn b_func() { super::clib::c_func2() }
}
//------------------------- c.rs ---------------------------
#[crate_type = "lib"];
#[link(package_id = "clib", name = "clib", vers = "0.1")];
use c_inner::c_func;
pub mod c_inner {
pub fn c_func() { println("c_func invocation"); }
}
pub fn c_func2() { c_func(); }
//-----------------> CUT HERE <--------------------
What I'm trying to say is it could look like that:
//-----------------> CUT HERE <--------------------
//------------------------- a.rs ---------------------------
use b::b_inner::b_func;
pub mod a_inner {
pub fn a_func() { b_func(); }
}
fn main() {
a_inner::a_func();
}
//------------------------- b.rs ---------------------------
use clib::clib::c_func2;
pub mod b_inner {
pub fn b_func() { c_func2() }
}
//------------------------- c.rs ---------------------------
#[crate_type = "lib"];
#[link(package_id = "clib", name = "clib", vers = "0.1")];
use c_inner::c_func;
pub mod c_inner {
pub fn c_func() { println("c_func invocation"); }
}
pub fn c_func2() { c_func(); }
//-----------------> CUT HERE <--------------------
So instead of using *mod*, *extern mod* and *use, *just *use *seems to be
sufficient.
BTW. Few interesting notices:
1) Inside b_func() I had to use super, otherwise clib was not visible.
2) Code like this doesn't compile:
//-----------------> CUT HERE <--------------------
//------------------------- a.rs ---------------------------
use b::b_inner::b_func;
mod b;
pub mod a_inner {
pub fn a_func() { b_func(); }
}
fn main() {
a_inner::a_func();
}
//-----------------> CUT HERE <--------------------
*a.rs:6:20: 6:26 error: unresolved name `b_func`.*
*a.rs:6 <http://a.rs:6> pub fn a_func() { b_func(); }*
^~~~~~
3) Someone said before that I need to use* extern mod* just once, if I
understood correctly.
I found it's not the case. If I'll try to change a.rs like that:
//-----------------> CUT HERE <--------------------
//------------------------- a.rs ---------------------------
mod b;
pub mod a_inner {
pub fn a_func() { super::clib::c_func2(); }
}
fn main() {
a_inner::a_func();
}
//-----------------> CUT HERE <--------------------
It won't compile. Moving *extern mod clib; *from b.rs to a.rs makes
a.rscompiling obviously, but
b.rs broken.
This means to make it work correctly I need to add *extern mod clib; *in
both files (then it compiles and works).
This can lead to have code like extern mod rust = "github.com/mozilla/rust";
in multiple files, which I think is not manageable.
Even worse, what if someone will specify different versions of the same lib?
(Actually I checked and I see that compiler just printf note about that.
Does it mean it's correct and supported behavior?)
4) #[feature(globs)] seems to be broken. I.e. this doesn't compile:
//------------------------- a.rs ---------------------------
#[feature(globs)];
use b::*;
// (...)
//------------------------- a.rs ---------------------------
But maybe I'm just trying to use it in wrong way.
I also didn't managed to get #[path=""] working correctly, but I think it's
enough for now...
Overall my opinion on current module is that if it could be simplified then
it should be.
And don't get me wrong. I love how current system let me create and manage
libs and dependencies without complicated makefiles.
And it is conceptually really simple. So I don't talk about stripping down
any features.
I just think syntax can (?) and should follow that conceptual simplicity
and it should be a bit more consistent
(i.e. some thinks are managed by annotations and some but parameters in
round brackets, which seems to be a bit random, etc).
Sorry for long post ;)
Best regards,
Piotr Kukielka
2013/12/13 Felix S. Klock II <[email protected]>
> On 13/12/2013 12:53, spir wrote:
>
>> I think this is a good possibility, make the module/crate organisation
>> mirror the filesystem (or the opposite):
>> * 1 module = 1 file of code
>> * 1 package = 1 dir
>> This may be limiting at times, possibility one may want multi-module
>> files and multi-file modules.
>>
> Yes, one may indeed want those things. In particular, *I* want
> multi-module files.
>
> I do not want to move towards a Java-style approach where the package
> nesting structure needs to match the file/directory nesting structure.
> Being able to declare nested modules within a file is very useful for
> flexible namespace control.
>
> I like our current support for nesting modules in files, and breaking them
> out into separate files as one wants.
>
> But then again, I also think that the current approach of { `extern
> mod`... `use`... `mod`... } is pretty understandable once you, well,
> understand it. My main complaint has been about the slightly
> context-dependent interpretation of paths [1], but that's pretty minor. So
> perhaps I have the wrong point-of-view for interpreting these suggestions
> for change.
>
> Cheers,
> -Felix
>
> [1] https://github.com/mozilla/rust/issues/10910
>
>
> On 13/12/2013 12:53, spir wrote:
>
>> On 12/13/2013 11:43 AM, Diggory Hardy wrote:
>>
>>> What would you do?
>>>
>>> Have no structure (no mod)? Or automatically create it from the file
>>> structure?
>>>
>>
>> I think this is a good possibility, make the module/crate organisation
>> mirror the filesystem (or the opposite):
>> * 1 module = 1 file of code
>> * 1 package = 1 dir
>> This may be limiting at times, possibility one may want multi-module
>> files and multi-file modules. But this forms a good, simple base (anyway,
>> we have mini & maxi modules & code files, whatever the logical & physical
>> organisations). Another point is that very often we have package (I mean
>> crate ;-) sub-dirs which are not packages themselves. Then, as usual, we'd
>> have a special code file representing a package at its top dir (the same
>> name as the package, or a magic name like 'main').
>>
>> Then, module sharing is code file sharing, and package management is dir
>> management (trivially .zip-ed or .tar.gz-ed, and then the name "package" is
>> here for something).
>>
>> Denis
>> _______________________________________________
>> Rust-dev mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> --
> irc: pnkfelix on irc.mozilla.org
> email: {fklock, pnkfelix}@mozilla.com
>
>
> _______________________________________________
> 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
