[rust-dev] Modules and visibility

Matthias Einwag matthias.einwag at googlemail.com
Fri Jan 24 10:27:10 PST 2014

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

> 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
> 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
> per module". Maybe having triggerable linter can help people choosing
> 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
> the declaration/definition splitting of function. However the python or
> 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
> see clearly in the rust code the list of public methods of a given class.
> there is room for improvement.
> For the internal visibility, I really enjoy the python's way of life "you
> access to anything at your own risk", however I finally don't think it's a
> 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

More information about the Rust-dev mailing list