Thanks a lot Daniel for your suggestions. As per my understanding
Clojure for Java and .Net are two implementations of the same
language, but they have to support different things because the
underlying platforms support different things - e.g. extension methods
(are in C# but most likely not in Java).
I realized the naming convention of methods. Similarly, what should be
the convention for naming method parameters? Is it pascalCase?
Also, I'll have to check when-let and re-find, I am still not familiar
with it.
As for the program, I had to write a simple cmd line tool a few days
back at my work, which converts images from one format to other (by
using an external tool) and copies the converted images to specific
folders (based on the file names), hence the subfolder name fn.
On Jul 1, 1:58 am, Daniel Lyons <fus...@storytotell.org> wrote:
> Manoj,
>
> In case this helps, I've had a bit longer to dwell on this problem and
> I have a couple of ideas. I do think this raises the general question
> of, are Clojure .NET and Clojure Java two different languages or two
> implementations of the same language? Normally in a situation like
> this (say, Jython and Python) I would say that they should be two
> implementations of the same language but the situation is complicated
> by the fact that Clojure code relies heavily on Java objects since the
> policy is not to wrap everything. I'm not sure how the subject of
> Clojure .NET / Java portability has been approached but my naïve guess
> is that it would revolve around separating Java dependencies and .NET
> dependencies from pure Clojure code. Is anyone else addressing these
> issues in their own code at this time?
>
> Back to your code. First of all, to simplify things, it's probably a
> good idea to decouple your I/O from your parsing, since the parsing
> can be functional. First I rewrote starts-with-hmorx into this:
>
> (defn starts-with-hm-or-x [name]
> (#{\H \M \X} (.charAt name 0)))
>
> Which I think is simpler, building on the fact that sets can be used
> as functions, but then I thought it would probably be better to
> rewrite the functions into one that gets the information from the
> filesystem and another one that gets the information you want out:
>
> (defn parse-subfolder-name
> [name]
> (or
> (when-let [[_ digit] (re-find #"(\d).*" name)]
> (Integer/parseInt digit))
> (when-let [[_ hmx] (re-find #"([hHmMxX]).*" name)]
> (.toLowerCase hmx))
> "other"))
>
> Unfortunately I'm still dependent on some Java API stuff in there, but
> I think you can probably translate to the .NET equivalents. This is
> easier to test at the REPL:
>
> user> (parse-subfolder-name "0stuf")
> 0
> user> (parse-subfolder-name "Hstuf")
> "h"
> user> (parse-subfolder-name "stuf")
> "other"
>
> Then I'd set about handling the loading of the filename and
> dispatching it:
>
> (defn get-subfolder-name
> [filename]
> (parse-subfolder-name
> (.ToString (Path/GetFileNameWithoutExtensions filename))))
>
> Now it should be easier to determine where the problem is, either in
> the I/O code or in the functional code which is easier to test at the
> REPL.
>
> As an aside, I'd recommend that you follow the naming convention of
> using lowercase function names with words separated by hypens (get-
> subfolder-name) rather than CamelCase (GetSubfolderName). Also, it
> doesn't look to me like GetSubfolderName is really returning a
> subfolder's name but I'm not quite sure what it is doing either. Are
> you working on an app with specific meaning tied to the first
> character of a path name or is this a .NET filesystem thing? Just
> curious.
>
> Thanks and hope this helps,
>
> —
> Daniel Lyons
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
