Libstuff is a library, in the system semantic (linux, same for windows). It
may contain one crate, it should be still named after what it is in the
system, but it is not properly speaking part of the rust semantic.
However alone it is almost useless, you need extra data to.locate, index,
install,
On 12/14/2013 05:28 AM, Liigo Zhuang wrote:
There is an official tool called rustpkg, and there is a attribute call
pkgid, so you cann't just easily saying there is no package in rust. If
no package, why not using rustcrate and crateid for consistency? (I do
not think 'crate' is a good name,
On 13/12/13 20:29, Liigo Zhuang wrote:
looks like a good idea.
I always think extern mod extra is repetitious, because, when i use
extra::Something, the compiler always know I'm using the mod extra.
You only need one `extern mod extra` per program which is hardly
repetitive, and, what if
If you have a submodule called `extra`, how can the compiler tell that you
want to be importing from it?
I think I covered this in my description:
If there is matching import in scope and it isn't labeled with resource
path marker then first check local mods, and if nothing is found then scan
libs
Three jobs, three key words:
1) creating structure: `mod foo { ... }` is used to organise code into modules
2) external references: `extern mod foo` imports foo, but without any name
binding (e.g. Java and Python's import statements also bind names)
3) creating aliases/binding names: `use
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
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.
On 12/13/2013 12:53 PM, 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.
I actually really like the way python modules are organised, it's really
helpfulfor developping, really easy for unit testing just some modules. If
it is that way by default, and allow different structure by adding some
boilderplate, that could be really interesting
-
Gaetan
2013/12/13
Yup. It's a known problem in the Haskell community that folks wish to
eventually move away from.
On Friday, December 13, 2013, György Andrasek wrote:
On 12/13/2013 12:53 PM, spir wrote:
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the
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
On 12/13/2013 02:57 PM, Piotr Kukiełka wrote:
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
Thanks, you are right.
So correcting myself:
1) It doesn't require super, ::b works as well. It makes sense.
2) It works if *use* is in right scope, in this case inside a_inner. I must
admit it's a bit surprising that imports are not inherited from the parent
scope.
4) #[feature(globs)] works
package and module, we only need one. Most other language only have
one. The more, the more complicate.
libstd.so: What we call it? library package crate?? other language
usually call it library.
std::io::fs: We call it module, other language usually call it package
or module.
So, whatever we
On 12/13/13 4:56 PM, Liigo Zhuang wrote:
package and module, we only need one. Most other language only have
one. The more, the more complicate.
libstd.so: What we call it? library package crate?? other language
usually call it library.
std::io::fs: We call it module, other language usually
Packages don't really exist as a concept at all. Supposedly `rustpkg`
deals with packages but in reality, it just deals with crates.
And they're certainly not part of the module system.
On Fri, Dec 13, 2013 at 8:14 PM, Liigo Zhuang com.li...@gmail.com wrote:
What is the distinction of package
On 12/14/2013 02:14 AM, Liigo Zhuang wrote:
What is the distinction of package and crate in Rust?
Crate is the compilation unit. Package is what you say it is, the Rust
manual does not mention that word.
___
Rust-dev mailing list
2013/12/14 Corey Richardson co...@octayn.net
Packages don't really exist as a concept at all. Supposedly `rustpkg`
deals with packages but in reality, it just deals with crates.
And they're certainly not part of the module system.
2013/12/14 György Andrasek jur...@gmail.com
On 12/14/2013
18 matches
Mail list logo
