You use case is one I've heard before particularly the notion of
having a scratchpad for doing work you are not committed to yet or at
least have not fully flushed out where things belong (namespaces).
The Enclojure Clojure project template is intended to get someone up
and running immediately with an AOT project.
Creating a project in Enclojure and adding files does help
considerably (IMHO) with keeping things in line with compilation and
code loading within the Clojure model. I tend to create a file within
the project I'm using in a namespace and use that as a scratchpad. I
do the refactoring by hand (not unlike what you are describing above)
and this should be automated. It's on the list of things to do in
Enclojure :)
What I'm thinking about with the Java projects with "Adding Clojure
Support" should not require you to understand anything about
intermingling code at all. What I'm attempting to do is _not_
reinvent all the good work done for supporting app servers and the
like which I _should_ be able to piggy back on.
That being said, one main issue for me in making this work is ensuring
the compilation of Clojure and Java code can be done seamlessly for
the developer which means I have to be able to participate in the
build process of these projects which I'm hoping will be easy for me
to do...
Thanks for the detailed description!
Eric
On Oct 14, 8:36 pm, Mark Engelberg <mark.engelb...@gmail.com> wrote:
> I think I can best express my thoughts by first explaining my Clojure
> workflow in Emacs.
> On my computer, I have a directory c:\devel\clojure. In this file, I
> put all my clojure files.
> Let's say I want to write a banking simulation. I might start by
> creating a file called banking.clj in emacs. Initially, I don't
> declare any sort of namespace at the top of the file. I just start
> adding functions, and hitting Ctrl-C Ctrl-K to load the file into the
> REPL. I play around in the REPL. Eventually, when I feel I've got
> something reusable and worthy of being required from other files, I go
> ahead and add a namespace (which must match the file so that it can be
> found by the "require" statement of other files). Then, if I want to
> test it further in the REPL, not only do I have to hit Ctrl-C Ctrl-K,
> but I also have to type (in-ns 'banking)
> Anyway, as long as I keep everything in one directory, and make the
> namespaces match the filename, everything pretty much works as I
> expect it to. Sometimes I effectively make a "project" by putting
> related files in a subdirectory off my devel\clojure directory, but
> then I have to change all the namespaces to match the subdirectory.
> For example, if I end up with two banking-related files (say debit.clj
> and credit.clj) in a banking subdirectory, then the namespaces must be
> banking.debit and banking.credit. I must say I find this redundancy
> between filenames and namespaces annoying, and it makes it difficult
> to rename files or move them around, or rename the directories they
> are in, but as long as I keep things consistent, it all works.
> The one time I tried to do AOT-compilation of Clojure code using my
> Emacs/directory-based organization, it was a total pain to get
> everything set up so that it would compile it to a location where the
> other files could see it. Blech. My guess is that Enclojure improves
> upon this considerably, but this isn't my main use case for Clojure.
> Although my Emacs setup works, there are a lot of things I don't like
> about it. So I'm looking forward to trying out Enclojure.
> But I'm coming at this from a perspective of not having used Netbeans
> before. So when I start up Netbeans I have to understand what a
> project is, and what it means to have all the files in one project,
> and how that interacts with Clojure's concept of namespaces. I was a
> little surprised when the skeleton project created a stub gen-class
> with a main. On the one hand, it makes me feel that building a
> "compiled project" in Enclojure is probably easier than what I've
> dealt with before, but on the other hand, it leaves me unsure how to
> do the quick file-editing-executing-in-REPL I'm used to doing. I'll
> figure it out eventually, but for now, I'm still a bit confused.
> When you say you're moving towards a "Java project only" concept, my
> initial reaction is that it sounds like you're going to focus even
> more on users who need to intermingle Java and Clojure code, and that
> maybe I'm going to need an even deeper understanding of
> projects/classpaths/Java organization to get anything done in
> Enclojure. And I personally am more interested in using Enclojure to
> work almost exclusively with Clojure code and very rarely with Java.
> But if the choice of "project" really has no bearing on these issues,
> then I don't really care.