I've read this thread, but it seems like there are no load and load-file in ClojureScript. Is it possible to separate a single namespace over multiple files?
The reason I want to do that is because I'm using Om and I want to separate components into different files. I can do it using separate namespaces, but then I will have to write the same requires in the beginning of each file and also the only way to call those components in the main file is like that:
(:require [some-project.sidebar :as sidebar])
...
(om/build sidebar/sidebar app-state)
i.e. I have to specify namespace before each component's name, which doesn't look pretty. Any ideas on how to improve it? I'm new to Clojure and ClojureScript, so maybe I'm missing something obvious?
There are a few things to note here
You can use :refer in your :require to import unqualified vars into a namespace. This is ok if there are a few, but can quickly get unwieldy if you tried to do it for everything.
Clojure applications are often structured in a tree like fashion where a main namespace requires sub namespaces, and so on, so you won't necessarily be importing the same namespaces into every namespace.
Even if it was possible to split a namespace across multiple files, it wouldn't be idiomatic Clojure. One file = one namespace is the norm.
If you wanted, you can def vars from one namespace into another to make one 'master' namespace to use in your other namespaces.
If you want to minimise the number of imports you have to do, make fewer namespaces and make them bigger.
Related
One of the greatest offenses in the C++ community is writing using namespace xyz instead of writing the namespace out everywhere in the code.
Ruby has the functional equivalent of namespaces via modules. All of the proposed issues with using an entire namespace in C++ are perfectly valid for including an entire module in Ruby. But in Ruby it is not condemned to do this.
So why doesn't Ruby have the same namespace controvery as C++? What is the difference between including a module in Ruby and using a namspace in C++?
There is a strong cultural component to this since it is perfectly valid to import an entire namespace... BUT
c++ has Argument Dependent Lookup (ADL) and ruby does not. As a program grows, it becomes more and more likely that an innocent using namespace x will accidentally change the meaning of the entire program, because the compiler happens to find a better match in the x:: namespace for a function that has the same name and similar signature to one in the (for example) y:: namespace.
This is the reason for the caution on this issue.
You generally "include" a module when you are mixing-in a functionality from one module into another. There are some parallels between mix-ins and inheritance where you are "absorbing" the functionality of one module/class into the current module/class. Here's a comparison of the two.
However, if you aren't mixing-in functionality, then you would always use the proper namespace qualifier of the module to access its functions.
You normally don't pull everything via an include at top level (the equivalent of using namespace in C++). you "mix" it in where you need functionality from that specific module.
I am building a library that consists of many different classes and files but they are all related so I am thinking that putting them in the same namespace is a good idea; this also allows me to use less risky generic/simple class names since name collision inside the namespace is not an issue.
Is the process of using the same namespace for many different files as simple as simply putting all the classes inside the same-named namespace?
ClassA.h, ClassB.h, ClassC.h, etc contain this:
namespace Whatever{
...Class definition
}
Yes you can surely move ahead with this idea. If we use same namespace name in different files those get automatically clubbed into one.
As per the comment by Joachim Pileborg, this is acceptable organizational style, and is in fact used by the STL itself.
When using nested namespaces sometimes fully qualified names end up being quite long. I know I can use namespace abc = aaa::bbb::ccc for reducing the amount of typing (it may also improve readability in some cases).
I am not sure, however, what is the best way to achieve this renaming across all the files in a project. The straightforward approach (i.e., to rename long namespaces in a per-use basis) might lead to end up using different short names for the same fully qualified name in different files. So, I was thinking to come up with a more consistent way to do this.
For instance, let's assume something like:
project
|- client
| |- core
| |- plugin
| |- util
|- server
...
I was thinking to create one header per directory including the reduced names. For instance, project/client/core/core.h would contain namespace pr_cl_core = project::client::core (I know the example for this short name is rather poor, but in real projects they make more sense). Then, I would include core.h into all the header files in project/client/core so that when a header from that directory is included in, let's say, project/client/plugin/plugin_foo.h, the short namespace versions are readily available.
Is this a good approach to do so? Is there any other better way?
I have found several questions on C++ namespaces on SO (for instance, 1 and 2), but none of them relates to how to solve namespace renaming in a project-wide manner.
EDIT: Additionally, such a mechanism could be used to systematically rename long namespaces (such as Boost's ones) for a whole project. For instance, I typically rename some namespaces like:
namespace ip = boost::asio::ip;
namespace ptime = boost::posix_time;
Currently I do this on a per translation-unit basis, but I would like to do it using a global approach for the whole project.
I would argue that if you repeatedly have to type long namespace names, then something is wrong in your namespace hierarchy.
Suppose you would have the same with classes, repeatedly finding yourself typing obj->sub()->subsub()->some_method(). This would be a violation of the Law of Demeter. In the case of classes, you would refactor your code (by writing wrapper functions) so that classes down in the hierarchy only have to access methods one level up.
The same should be done with namespaces: if you have to call project::client::core then you should write wrapper functions/classes in client to expose the necessary interfaces to project. If you need to do this all over the place, why not flatten your namespace structure so that client and core are at the same level?
The fact that Boost uses nested namespace is only partly true, because most of the nested namespaces like aux and detail are not supposed to be called by clients. E.g. Boost.MPL is a really good example of a library that is careful not to gratuitously expose nested namespaces.
I come from a c# background where everything has its own namespace, but this practice appears to be uncommon in the c++ world. Should I wrap my code in it's own namespace, the unnamed namespace, or no namespace?
Many C++ developers do not use namespaces, sadly. When I started with C++, I didn't use them for a long time, until I came to the conclusion that I can do better using namespaces.
Many libraries work around namespaces by putting prefixes before names. For example, wxWidgets puts the characters "wx" before everything. Qt puts "Q" before everything. It's nothing really wrong with that, but it requires you to type that prefix all over again, even though when it can be deduced from the context which declarations you mean. Namespaces have a hierarchic order. Names that are lexically closer to the point that reference them are found earlier. So if you reference "Window" within your GUI framework, it will find "my::gui::Window", instead of "::Window".
Namespaces enable some nice features that can't be used without them. For example, if you put your class into a namespace, you can define free functions within that namespace. You then call the function without putting the namespace in front by importing all names, or selectively only some of them into the current scope ("using declaration").
Nowadays, I don't do any project anymore without using them. They make it so easy not to type the same prefix all over again, but still have good organization and avoidance of name-pollution of the global namespace.
Depends, if your code is library code, please wrap it in namespaces, that is the practice in C++. If your code is only a very simple application that doesn't interact with anything else, like a hello world sort of app, there is no need for namespaces, because its redundant.
And since namespaces aren't required the code snippets and examples on the web rarely use them but most real projects do use them.
I just discovered Google's c++ style guide and they have namespace guidelines.
The whole guide is worth reading, but to summarize, they say:
Add unnamed namespaces to .cc files, but not .h files.
Wrap entire (after includes/declarations) .cc and .h files in named namespaces.
Namespaces do not increment the indent level.
At the closing brace for a namespace write } // namespace.
Don't declare anything in std, because it is undefined.
using the using directive is forbidden.
the using declaration is allowed in functions, methods, and classes.
namespace aliases are allowed anywhere.
It really depends upon whether you expect there to be any conflicts.
Two scenarios;
1) If you are creating code that may be used by others (e.g libraries) then there could be namespace clashes so using your own namespace is a good idea.
2) If you are using third-party libraries their code may not be namespaced and could conflict with yours.
I would also say that if you expect your code to be sizable and cover many different areas (math/physics/rendering) then using namespaces does make the code easier to grok, particularly for types that are not obviously classified.
We had problems wrapping code in managed C++ that uses our common libraries here.
Some classes had the same names as System class in the .NET library (i.e. System.Console).
We had to do some ugly macro patches to workaround these problems.
Using namespaces at the beginning would have prevented this.
You only really need namespaces if there's a risk of names conflict - some globally seen function or variable or class is defined more than once. Otherwise you'll do just fine with no namespace - just name your classes so that they don't duplicate runtime library classes and make global functions/variable to be static members of some reasonable classes.
I'd say that it's a good idea, if for no other reason than to keep your stuff from getting stepped on when mixed with other third-party code.
I try to go even farther than that by putting as many variables and functions as I can into classes. But that's sometimes harder to do than it should be (compared to other OO languages).
but this practice appears to be
uncommon in the c++ world
Really. All the code I see seems to be wrapped in a namespace.
I use the same type of convention I see in Java (except I drop the com).
In Java
package com.<Company>.<Product>.<Package>;
In C++
namespace <Company>
{
namespace <Product>
{
namespace <Package>
{
}
}
}
I think most C++ programmers here would agree that polluting the global namespace is a bad idea, but are there times when this rule can be ignored?
For example, I have a type that I need to use all over a particular application - should I define it thus:
mytypes.h
typedef int MY_TYPE;
foo.cpp
MY_TYPE myType;
Or use a namespace:
mytypes.h
namespace ns {
typedef int MY_TYPE;
}
foo.cpp
ns::MY_TYPE myType;
...
using namespace ns;
MY_TYPE myType;
Which do you prefer? Are there times when it is acceptable to use the first method?
You can define your type in a separate namespace, and use
using ns::MY_TYPE;
I use namespaces for partitioning library code from application-specific code, and in a big project to partition the various modules that make up the project.
The global namespace is thus useful for application-specific types and functions that are used across multiple modules in the application.
So, if your MY_TYPE is used throughout your application, put it in the global namespace, otherwise put it in a named namespace.
Libraries must not, Applications may.
When multiple people work on an application, of course you need clear rules, and the clearest rule is "don't". However, this isn't ideal in all cases.
"using" statements should go only on top of CPP files, never in headers - but that complicates writing templates since - for most compilers in the near future - they need to reside in headers.
In my experience (mostly small team with a large but well-partioned project), namespace pollution isn't much of a problem as long a you controll the respective code, and insist on descriptive names. The cases I remember were few and far between and easily dealt with. There were major problems with 3rd party libraries, though - even with source available.
YMMV with a huge team or a huge project that goes into a single compile.
I don't agree with using the global namespace at all (well, except for main, of course). For things that are used across the whole application, you can simply use using namespace at the top of your .cpp files, after all the relevant #include lines.