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
