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
libs)
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".
--
Lee
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 <[email protected]>
To: Patrick Walton <[email protected]>
Cc: "[email protected]" <[email protected]>
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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
