Hi everyone,
During my first steps with Rust (and working on this:
https://github.com/mozilla/rust/issues/11165) I realized that I had much
more trouble with the module and privacy system than in any other language
I worked with up to date. I really had no clear idea of how to structure my
source
On 1/22/14 12:37 PM, Matthias Einwag wrote:
1. A real splitting between source files and modules
One solution is an alternative include to mod Otherfile; That would
not automatically create a new module and put the content of the file in it.
So basically the same as C++ include. I know th
On Thu, Jan 23, 2014 at 7:59 PM, Patrick Walton wrote:
> On 1/22/14 12:37 PM, Matthias Einwag wrote:
>
>> 1. A real splitting between source files and modules
>> One solution is an alternative include to mod Otherfile; That would
>> not automatically create a new module and put the content of
We all very much do NOT have IDEs. ;)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Ehhh, my phrasing on that one was poor. What I was trying to say is
that there are a significant number of users of Rust who do not have
IDEs, and adding anything that would _require_ you to use an IDE with
Rust is a significant drawback.
If an IDE floats your boat, no complaints from me. As long
Hi,
with similar engineering reasons I can argue the same way that splitting
into multiple makes sense:
1. When you name the file like our object you can use jump to file as
a replacement for a Jump to Definition in more complex IDEs.
2. When you layout your folders like the modul
I will say that I actually really like Go's approach to modules. It uses a
folder -> module mapping instead, so a module can consist of any number of
source files provided they all live in the same directory. If you prefer
your modules to be one big source file each, then that's easily done, but
th
On 1/23/14 8:39 PM, Damien Radtke wrote:
I will say that I actually really like Go's approach to modules. It uses
a folder -> module mapping instead, so a module can consist of any
number of source files provided they all live in the same directory. If
you prefer your modules to be one big source
I don't see the point to link the logical structure of the code with the
IDE or editor you use. There is no link between them, or it is a good
practice NOT to do any assumption. If one want to code with
vi/emacs/sublime or eclipse or any other one, the build system and
structure of the code should
On 23/01/14 22:23, Steve Klabnik wrote:
Ehhh, my phrasing on that one was poor. What I was trying to say is
that there are a significant number of users of Rust who do not have
IDEs, and adding anything that would _require_ you to use an IDE with
Rust is a significant drawback.
If an IDE floats
I've started to work on better implementation of ctags.
-
Gaetan
2014/1/24 Lee Braiden
> On 23/01/14 22:23, Steve Klabnik wrote:
>
>> Ehhh, my phrasing on that one was poor. What I was trying to say is
>> that there are a significant number of users of Rust who do not have
>> IDEs, and ad
as
> Date: Fri, 24 Jan 2014 09:44:36 +0100
> From: Gaetan
> To: Patrick Walton
> Cc: "rust-dev@mozilla.org"
> Subject: Re: [rust-dev] Modules and visibility
> Message-ID:
>mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
&
you actually wanted to build.
Best regards
Matthias
Date: Fri, 24 Jan 2014 09:44:36 +0100
From: Gaetan
To: Patrick Walton
Cc: "rust-dev@mozilla.org"
Subject: Re: [rust-dev] Modules and visibility
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
I don&#x
On Fri, Jan 24, 2014 at 4:02 AM, Lee Braiden wrote:
> I think the best solution to that would be some sort of daemon that takes a
> top-level project definition, or a set of files, compiles them, monitors for
> changes, and interactively answers questions about it via some simple API:
Note that d
14 matches
Mail list logo
