I have read in several places that single segment namespaces are discouraged in clojure.
Indeed almost every library I've seen has (require 'lib.core) instead of (require 'lib).
Why?
Edit: I am a bit stupid. Extra credit will be given for a concise example of how a single segment namespace might be a bad thing.
Java discourages the use of the default package because you can't refer to anything in it from any other package. If you pre-compile a one-segment Clojure namespace, you'll get a Java class in the default package. If anyone at any time wants to use your library from Java, he will be stopped dead by this triviality. As there is no good reason in favor of using a single-segment namespace, and there is this one well-defined reason not to, it is fair to say that single-segment namespaces should be a discouraged practice in Clojure.
Single segment namespaces have issues with Java interop. Some things may break in unexpected ways. See also https://groups.google.com/forum/?fromgroups=#!topic/clojure/gOffhotk25Y
Related
I saw the this question and its answers but they slightly miss the point of how best to author core.clj to make a library easily shared and understood.
What is the purpose of core.clj file?
One answer said we could do anything we want but probably shouldn't. :) I am looking for the path of least resistance, so core.clj it is.
But another answer said users would be using that path to get access to my library. That makes me think I have it backwards, with core being a few fundamentals. Instead it sounds like core.clj (its namespace) should pull in my other paths and effectively serve as its API.
Like the accepted answer to your linked question says, the core namespace typically holds the entry point(s) to an application or to your library. That being said, this is only a convention, not a necessity, you technically don't need to have a core module at all.
If your core modules holds only a few fundamentals that are used by other code fragments and you expect users of your library to call functions foo and bar from the namespace yourlib.foobar as entry points, you would probably be better of to rename your core module to something else to avoid confusing people checking out the code of your library. However, one notable pattern I've seen is that some people put the entry points / functions in a yourlib.clj module (yourlib namespace, not yourlib.yourlib), which serve as a thin facade to calls to functions in yourlib.core. So, in a sense, yourlib.core is really the "core" of your library, but doesn't provide the entry points itself.
Apologies in advance for the somewhat discursive nature of this clump of related questions; I hope the answers will be a useful resource for newcomers to Clojure.
I have just begun to learn Clojure, motivated in part by this essay. I'm not a professional developer but I have several decades of programming experience (ARexx, VB/VBScript/VBA, then Perl and daily use of R starting in 2011). My platform is Windows 7 64-bit. I'm using Emacs 24.3, cider 20131221 and Leiningen 2.3.3 on Java 1.7.0_45 Java Hotspot 64-bit server. I have bought Clojure Programming and the Clojure Data Analysis Cookbook and dipped into both. I have found them promising but I am getting lost in the detail.
Obviously the thing to do is to get stuck in and experiment with code exercises and small tasks, but the immediate problem for me has been the complexity of structuring, organising and even just plain running projects in Clojure. With R I can get away with a file of plain text containing the bulk of the code, perhaps with one or two others containing common functions for larger projects.
Clojure is very different and with no experience in Java I am struggling to put the pieces together. Clojure Programming has a whole chapter on organising and building projects, but it is so comprehensive that conversely I'm finding it difficult to tease out the information relevant to me now. I guess I'm looking for something like this answer on Swank, but the tools seem to have moved on since then. So here goes.
Leiningen produces amongst other things a project.clj file that contains the project definition and dependencies. I think I get this. Can I use this file for code not related to the definition, below the defproject, or is it best to leave this untouched and have the code itself in different clj file(s)?
If the answer is to leave the project.clj file alone, how is the relationship between that and other files established? Is it simply that all the clj files in the project folder are counted part of the project?
How do I define the main code file, the 'entry point' of the project? Let's say I have project.clj and main.clj with some helper functions in common.clj - how are the relations between these three files defined? I can call functions from main.clj but how does the project know that main is the core of the project if/when I package the project into an uberjar?
If I have a number of clj files, what is the best way to import functions? I have read about require and use (and import and refer and...) but I don't fully understand the difference and those two keywords are difficult to search for. The examples for REPL in the Clojure Data Analysis Cookbook most often opt for use. I found a similar question but it was a little over my head.
This is more tool-specific, but as Emacs seems to be widely used it seems fair to ask: what's a good workflow to run small bits of code given (say) the main.clj example given above? Currently I just open the main.clj file in Emacs, do an M-x cider-jack-in to establish the REPL, experiment in the REPL, then when I want to try something I select the whole buffer and select Eval region from the CIDER menu (C-c C-R). Is this standard operating procedure or utterly misguided?
Is there a convention for defining namespaces? I think I understand that namespaces can cover multiple clj files and that ns is used to define the namespace. Should I explicitly define the namespace (at the beginning of) every file of code? Clojure Programming has some recommendations but I'm interested in input from other users.
Clojure programming says to "Use underscores in filenames when namespaces contain dashes. Very simply, if your namespace is to be com.my-project.foo, the source code for that namespace should be in a file located at com/my_project/foo.clj". (EDIT as explained in this useful answer and also this one). This restriction would never have occured to me. Are there any other gotchas with regard to naming namespaces and variables? R frequently uses dots in variable names but I guess given the Java connection that dots should generally be avoided?
No, don't put actual code in there unless you know what you are doing (e. g. generate the version number for defproject from the local git repository like in the repositories of juxt)
The project.clj is simply one big parameter to Clojures build tool leiningen. See an example here https://github.com/technomancy/leiningen/blob/master/sample.project.clj. For example, you could specifiy a different source directory than src in the :source-path.
Default is the -main function in project.core, but you can specify various different configurations in the project.clj.
require is preferred. :use imports all publics of a namespace unless you use it in conjunction with :only. Require let's you use an alias for an entire namespace with :as, but you can have the same effect from use with :only using :refer. Notice that in ClojureScript :use without :only is not even allowed.
This is normal. There are other combos like e.g. C-c C-k to reload the entire file of the buffer. If you find yourself entering too many forms into a REPL and would rather edit them in a separate buffer https://www.refheap.com/22235.
I like to experiment trying to name namespaces in in verbs rather than nouns, e. g. I prefer myproject.parse, myproject.interpret, over myproject.parser, myproject.interpreter etc. But that's a question of personal style. EDIT: Yes, explicitly define the naming of the namespace by its filename and the ns form at the beginning of the source file. It is unusual to have multiple source-file defining one namespace.
Afaic this is the only caveat regarding naming of namespace. You can hardly know it in advance.
I like your "worried" approach. You will (hopefully) find out that Clojure and especially Leiningen are almost nonsense-free in terms of these questions.
Regarding REPL use: I saw your comment under #Mars answer that you want to use a REPL in a fashion that you can re-use what you are entering. Two things:
Dynamic development is awesome, allowing you to test small components or functions interactively without the need to run an entire program written for that purpose.
If you find your self entering huge forms at the REPL that you intend to de-/recompose into functions or tests later, I recommend editing them in a seperate clj file that is not part of the project source (i. e. not in a namespace). You can then use this Emacs hack to eval forms from a Clojure buffer in the REPL. Ideally split your Emacs in two windows (C-x 3) with the nrepl buffer on one side and your .clj on the other side. Then use C-x C-. from within the clj file to have the form at point pasted into the nrepl and be evaluated. Installation instructions are at the link (and your .emacs file usually resides in the home directory).
#Igrapenthin's answers are great. Here are a few other thoughts.
On namespaces, this tutorial is great.
Just to clarify re #2: No, don't just put the .clj files anywhere under the project. They have to be under src/, or in whatever directories are listed (as strings) in the vector after :source-paths in project.clj, if that entry exists. Then strip off that initial path when you're making your namespace names. This drove me crazy until I figured it out. (People who know better, please correct me if something here isn't right.)
One #3, you need Igraphenthin's answer, but why not just start by evaluating expressions in the REPL? I've been working on a project on and off for weeks, and it does a lot, but my -main function still doesn't do anything. I just run whatever parts I'm working on. Well, you're used to languages with fully operational prompts--you decide.
EDIT: Whether or not you define the -main function to do anything, you can also put :use or :require keywords in the ns statement that defines the namespace for that same file. These will automatically get invoked when you start the REPL with lein repl, and so whatever you have made available through the ns keywords will be available at the REPL. That way, you have your previous work available, but you can play around with it in different ways in the REPL. (Also, if you don't like the default name for the file that's automatically loaded, you can redefine it in project.clj with :main. Igraphenthin alluded to that.)
Coming from a c# and java background, namespaces are nothing new to me and I have come to love the organizational structuring it brings to code.
I've been doing more work in c++ lately and I try to keep my coding habits as modern as possible. I have been toying around with some sandbox code, trying some new things and I would like to get some feedback on something I've been playing around with.
What I did was create a header file that explicitly declares a series of structured namespaces. The reason I did this is I wanted to layout a predefined structuring for namespaces to be used in the project. I realize that obviously the namespaces could be declared within any classes as the classes are defined but I like the idea of predefined structuring of the namespaces, such as (just an example):
namespace System
{
namespace IO
{
}
namespace Serialization
{
}
namespace Security
{
namespace Cryptography
{
}
}
}
etc. You get the idea.
My question is: Is there anything wrong with this approach? I figured it could be a good practice since it follows good coding practices with encapsulation and naming, etc.
I have seen some strange comments about similar things by old-school c++ devs, such as: "You're trying to combine Java and c++", or "Namespaces are just a way to mangle type names to avoid naming conflicts". I completely disagree with those opinions and don't feel those people are fully understanding the utility that namespaces can provide.
I don't think there's anything inherently "wrong" with it: you're documenting the intended structure of your namespaces.
But, ultimately, it's also pretty pointless, since nothing about this file stops namespaces with the same names from being [accidentally] created in a different structure, leaving you with a broken hierarchy there with actual types declared in it, and your intended hierarchy here with nothing at all in it.
Consequently I'd probably stick to standalone documentation for this sort of thing.
Declaring a namespace hierarchy in a header file is not very useful in practice; including the header file in any other files has no effect.
It seams to me you are trying to create a rule for people working on that project to follow, which or may or may not stick...it's all a matter of style and preference.
But there is nothing wrong with the approach it can do no harm.
I am a Java developer and C++ beginner. In Java, I can import objects easily using (Ctrl + Shift + O). In C++ however, I have to manually type #include each time, wasting my time. In addition, I often don't know where the required object is.
Is there an easy way to import or type "#include" automatically? If not, is there a plug-in or add-on to do that? I am using Eclipse IDE for Blackberry 10, along with C++ Cascades.
This is just how C++ works. The #include functionality is primitive compared to a Java import: each #include is simply replaced by the text of the included file (and so on, recursively) as if it had been copied and pasted in there.
This sometimes has advantages, and it's certainly simple, but it does mean that there's no reliable way to know ahead of time what is defined by a particular included file. So, if you need the vector type, for example, that is in vector; but if you need the va_list type, that is in stdarg.h. Generally, things are reasonably consistent, but not perfectly so, and there's nothing to enforce it anyway. This is probably why most IDEs don't provide much help for it. You just need to know what the rules are (if there are any) for the libraries you're using.
IDE support for C++ is generally not as good as it is for Java or C#. This is one example (there are plenty of other ones). If you are expecting a Java or C#-level of assistance, you are likely to end up disappointed. On the plus side, while sorting out the #include list is annoying, there are lots of other difficulties encountered when working with C++, so it rarely ends up the main problem.
see this bug report.
It seems that people have been discussing this for about 10 years but it's not implemented yet.
Personally I believe as a C++ programmer you should be trying to eliminate excessive use of include's in your files and use forward declarations instead therefore it's not a feature many programmers are looking for. If you prefer not to have that much control over the program, you can always code in java or c#.
I've often found myself wanting a way to undo the effect of a using statement or to include all of a namespace (such as std) but exclude a bit to be replaced (such as cout). For some reason this isn't possible. I am wondering if anyone knows why it was decided not to add this ability to the language? Is there some technical reason? I assume it wasn't just forgotten since it doesn't seem slated for C++0x either.
Just to clarify, I'm not looking for workarounds since Google can show me those. I'm looking for an explanation of why this is impossible, and why it was not considered (as far as I can tell) for inclusion in 0x.
A using directive brings a name or set of names into a given declarative scope.
You can't "un-using" for the same reason that you can't say
int x = 42;
// and later
[remove name x somehow]
There's no way to unintroduce names from a scope at all in C++, regardless where those names came from.
Given that it would overcomplicate name lookup (since names could be both added and removed from a scope), unless there is a really compelling use case, it's unlikely to be considered as a potential language feature.
This is because the using directive is not meant to be used for native C++ code. It was intended to help migrate C code to C++. In this context, "un-using" doesn't make sense.
-edit-
I should have been more specific. In this particular case, it looks like mstearn is using the using directive to include the std namespace globally. Doing this is generally a bad idea because it results in global namespace pollution, and should only be done in certain circumstances, like transitioning from another language to C++.
There are other situations where utilizing the using directive is fine (within a function, namespace composition). However "un-using" doesn't make sense in these situations either.
Mostly because there are workarounds that are sufficiently simple and straightforward that virtually nothing would be gained by including a "feature" for that specific purpose. Though I'm not sure he ever states it directly, I think you could argue that one of the guidelines in the design of C++ has always been to prefer general mechanisms to special-purpose ones, so using the existing scope system (for example) makes more sense than adding some special way to remove something from a scope after it's been introduced.