[rust-dev] Modules and visibility

Lee Braiden leebraid at gmail.com
Fri Jan 24 10:36:03 PST 2014

I think there are two issues here:

     * mental model <> on disk model impedence
     * on disk model <> editor model impedence

For the first, the editor should have some simple, capable interface to 
a rust syntax analyser (i.e., the front end or at something based on its 

For the second, though, I think there's no get out of jail free card 
just because you build some module locator interface for an IDE: people 
will still want to be able to find the right files quickly, and whether 
they're working in an IDE, in vim, or just feeding args to "cp".


On 24/01/14 18:27, Matthias Einwag wrote:
> I also think it makes no sense to align a programming language to what works
> best with one specific editor.
> Editors are highly controversial things, and vim even more so.
> Also if your are actively working on a module you will know most types that
> are defined in it anyway, and if not a jump to file where filename ==
> typename would in most cases help.
> Regarding Damiens counterargument that you can create small modules and
> reexport everything I see the 2 following problems:
> 1. You actively have to reexport everything. Without globs quite a bit of
> nonproductive work.
> 2. It messes up the visibility settings. Let's say I originally wanted to
> make a foomodule with two types Foo and Bar in it. I wanted Foo to  be able
> to access Bar's private methods. If I put everything in a file that's no
> problem. If I put them in several files I get foomodule::foo::Foo and
> foomodule::bar::Bar. And these can not call each others private methods.
> Maybe you could restructure it to foomodule::foo::bar::Bar or something like
> this and one special case would work, but then another one would fail. And
> you really don't get the hierarchy you actually wanted to build.
> Best regards
> Matthias
>> Date: Fri, 24 Jan 2014 09:44:36 +0100
>> From: Gaetan <gaetan at xeberon.net>
>> To: Patrick Walton <pcwalton at mozilla.com>
>> Cc: "rust-dev at mozilla.org" <rust-dev at mozilla.org>
>> Subject: Re: [rust-dev] Modules and visibility
>> Message-ID:
>> 	<CANK7tAHB5+CS96tKNoVyc6_n7iNd43vQ1jxS6K3GmqqTn2XUXg@
>> mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 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 be
>> agnostic.
>> For me the current structure of code of rust is totaly acceptable, even
> though
>> I would recommend to place unit test in a submodule of the tested one (ie
>> just splitting the code and its unit test in two files), but that is just
> a policy you
>> can enforce in your project (is there a lint for that?). Same for the "one
> class
>> per module". Maybe having triggerable linter can help people choosing
> there
>> convention.
>> What really annoy me is the fact that public method/class are not easilly
>> described in one place. On one hand, I like the headers in C++ where you
>> have a clear way of seeing which are the class/function your module
>> provides, with private stuff being pushed aside. To be more accurate, I
> like
>> the declaration/definition splitting of function. However the python or
> java
>> way is really handful where you just write the code directly. I don't know
>> which is best, I have the feeling rust is in the middle, but I sometime
> don't
>> see clearly in the rust code the list of public methods of a given class.
> Maybe
>> there is room for improvement.
>> For the internal visibility, I really enjoy the python's way of life "you
> can
>> access to anything at your own risk", however I finally don't think it's a
> good
>> practice. If you end up doing that, your design is wrong...
>> except for unit test where is it really useful to have direct and easy
> access to
>> private member to mock it...
>> -----
>> Gaetan
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

More information about the Rust-dev mailing list