On Fri, Oct 23, 2009 at 12:45 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
2009/10/23 Stewart, Robert <Robert.Stewart@sig.com>
Joel de Guzman wrote:
Fusion simply follows existing practice and extends it to the next level of modularity. There were two existing practice at the time when I wrote fusion:
lib/ lib.hpp
and
lib/ lib/lib.hpp
I find the latter redundant. I chose to follow the first.
+1, if I had to pick.
I really dislike things like all.hpp, as they end up turning into misnomers. I am willing to reconsider this position when gcc -Wall gets fixed into showing all warnings. :-)
IOW, there isn't one approach now. If we adopt a single approach, some code will break. Granted, in the latter case, lib/lib.hpp can be copied to lib.hpp and thus make it like the former, but at some point, lib/lib.hpp should be removed, and that will be a breaking change.
Why should it be removed? I can see picking a convention for future libraries and having a passionate volunteer (any takers? :-)) adding that convention to the current libraries, but I don't think cleaning up minor clutter is a good enough reason to break compatibility.
If you *really* have to have an all for whatever reason, why not follow the Python naming convention and name it __all__.hpp since it is something that includes everything and is easily factored out of tab expressions (which I use a *lot*) and is very noticeable.