tools.namespace ns parsing

[Petr]

 

 Hello. 

 I stumbled on a problem that caused me fair amount of frustration and I 
suspect that it could affect other users who start using tools.namespace. 

The problem is that clojure.code/ns macro is more lenient than what follows 
from it’s documentation. For example ‘use’ (or require) clause in vector is 
accepted e.g. “[:use ]” (see http://dev.clojure.org/jira/browse/TNS-21) 
or use clause with plain symbol (not keyword) is also OK, e.g. “(use ) 
(as in my case http://dev.clojure.org/jira/browse/TNS-30). And the way ns 
macro is expanded section in form “( )” would be replaced with 
“(clojure.core/ ... )”. However tools.namespace parses dependencies 
strictly according to doc. E.g.TNS-21 was closed as won’t fix for that 
reason. 

 This way there could be ns declarations  that have no compilation errors 
and work as one may think but are ignored by c.t.n’s parser.  Hence there 
could be actual dependencies that are silently ignored without any error or 
warning. 

 It seems that proper way to resolve this would be to rewrite ns macro to 
be more strict and accept only what’s described in documentation. But I 
suspect that this would lead to backward compatibility issues - some of 
existing code will break. 

 There is also possibility to rewrite 
clojure.tools.namespace.parse/deps-from-ns-decl so it does macroexpand and 
then looks for references to clojure.core/refer, clojure.core/require and 
clojure.core/use. This would match now ns actually works but one might not 
like this “implementation as specification”. 

 So I think that the good solution for now would be to have some validation 
function forns form. This function would issue a warning when some parts of 
namespace declaration could be ignored. This way unexpected behavior of 
clojure.tools.namespace.repl/refresh would not go unnoticed and this will 
make this library more user-friendly. 

What do you think would be a good solution for this?


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: what do you think about this code?

[Colin Yates]

From my own experience I think the following is relevant:
- functions are either specific to a context or abstract. Specific
functions need to be understood in the context of their call site and the
domain. Trying to make the  name of the specific functions capture the
entire context leads to noise. I would gently suggest that most of your
functions are specific, particularly the ones motivated by extracting
intent. They aren't and almost certainly can't be reusable so their call
site is part of their context. If you do want the  to be reusable then all
that context caotured in the label works against you
- again, the drive for reusability and the drive for future proofing
often lead us astray. In the solution domain there is only one sensible
interpretation of flipping vertically
- there is a hint of trying to make the code completely unambiguous and
self contained. This is also very similar to trying to make it idiot-proof.
I don't think any of these are achievable.  (Collective gasp whilst I out
on my fireproof coat). The syntax of any programming just isn't expressive
enough. Literate programming rocks, but that is because you aren't writing
code,  you are writing prose
- FP programmers tend to be more familiar with the inbuilt catalogue of
idiomatic  FP solutions, and dare I say I have met many more average OO
programmers than FP programmers :). This, coupled with the succinctness of
Clojure means idiomatic Clojure already contains a bunch of context. You
don't need to tell me what your code is doing because idiomatic Clojure
code is inherently readable *once I grok idiomatic Clojure*. For me,   I
found myself writing that sort of code at the beginning because I was
compensating for my lack of familiarity.

Nowadays, I tend to find it much more successful producing code that has a
certain number of assumptions:
- it will be maintained for far longer than it took to write (some of our
apps are decades old)
- readers will be competant wielders of the toolsets used
- idiomatic code is strongly preferred, as are coding conventions
- reader understands the problem domain and the solution domain

Trying to write code that is somehow a training manual, a design  document
etc. Is a hiding to nothing. The best communication tool I have found is
regular discussions with the relevant people. Corporate mindshare is best
maintained through words not code.

I said before, and I think I it needs repeating as you asked again, but no,
I dont think FP is any less concerned with the WHY or the HOW etc. I do
think it uses seperate tools to achieve the same goals. I would claim that
my code still satisfies all of the excellent points rsised in the best
practices literature,  but Clojure doesn't require the same verbosity.

As ever, this is only my opinion :).
On 14 Dec 2014 07:34, Philip Schwarz philip.johann.schw...@googlemail.com
wrote:

 Hi Leif,

 if I compare your suggestion

 (let [top-right (create-top-right-quadrant-for letter)
right (stack top-right
   (flip top-right))
diamond (beside (map reverse (drop-first-col right)) right)]
   (display diamond))


 with mine

   (let [top-right-quadrant (create-top-right-quadrant-for letter)
 top-left-quadrant (drop-first-column-and-reverse-every-row-of
 top-right-quadrant)
 top-half-of-diamond (join-together-side-by-side top-left-quadrant
 top-right-quadrant)
 bottom-half-of-diamond (flip-bottom-up-and-drop-first-row-of
 top-half-of-diamond)
 diamond (put-one-on-top-of-the-other top-half-of-diamond
 bottom-half-of-diamond)]

 yours is more inviting, and mine just looks like a barrage of verbiage.

 But with some judicious spacing and syntax highlighting, I think mine
 regains IMHO its effectiveness

   (let [*top-right-quadrant  **(**create-top-right-quadrant-for *
 *letter**)*
 *top-left-quadrant  * *(*
 *drop-first-column-and-reverse-every-row-of* *top-right-quadrant**)*
 *top-half-of-diamond* *(**join-together-side-by-side*
 *top-left-quadrant *
 *
 top-right-quadrant**)*
 *bottom-half-of-diamond*  *(*
 *flip-bottom-up-and-drop-first-row-of* *top-half-of-diamond)*
 *diamond* *(*put-one-on-top-of-the-other
 *top-half-of-diamond*

 *bottom-half-of-diamond**)*]
 even better if I adopt the 'beside' you suggested, and its 'above'
 counterpart:

   (let [*top-right-quadrant  **(**create-top-right-quadrant-for *
 *letter**)*
 *top-left-quadrant  * *(*
 *drop-first-column-and-reverse-every-row-of* *top-right-quadrant**)*
 *top-half-of-diamond* *(**beside* *top-left-quadrant *
 *top-right-quadrant**)*
 *bottom-half-of-diamond*  *(*
 *flip-bottom-up-and-drop-first-row-of* *top-half-of-diamond)*
 *diamond* *(*above *top-half-of-diamond*
*bottom-half-of-diamond**)*]

 Do you see the value of hiding the HOW at all? 

Re: what do you think about this code?

[Colin Yates]

Urk , one bit of my post came across wrong: I said before, and I think it
needs repeating as you asked again refers to how long these posts are and
I thought it had gotten lost in the walls of text. I didn't mean it in the
sanctimonious or condescending way it comes across.  I really shouldn't try
and write these responses whilst entertaining 4 under 10s :).
On 14 Dec 2014 10:32, Colin Yates colin.ya...@gmail.com wrote:

 From my own experience I think the following is relevant:
 - functions are either specific to a context or abstract. Specific
 functions need to be understood in the context of their call site and the
 domain. Trying to make the  name of the specific functions capture the
 entire context leads to noise. I would gently suggest that most of your
 functions are specific, particularly the ones motivated by extracting
 intent. They aren't and almost certainly can't be reusable so their call
 site is part of their context. If you do want the  to be reusable then all
 that context caotured in the label works against you
 - again, the drive for reusability and the drive for future proofing
 often lead us astray. In the solution domain there is only one sensible
 interpretation of flipping vertically
 - there is a hint of trying to make the code completely unambiguous and
 self contained. This is also very similar to trying to make it idiot-proof.
 I don't think any of these are achievable.  (Collective gasp whilst I out
 on my fireproof coat). The syntax of any programming just isn't expressive
 enough. Literate programming rocks, but that is because you aren't writing
 code,  you are writing prose
 - FP programmers tend to be more familiar with the inbuilt catalogue of
 idiomatic  FP solutions, and dare I say I have met many more average OO
 programmers than FP programmers :). This, coupled with the succinctness of
 Clojure means idiomatic Clojure already contains a bunch of context. You
 don't need to tell me what your code is doing because idiomatic Clojure
 code is inherently readable *once I grok idiomatic Clojure*. For me,   I
 found myself writing that sort of code at the beginning because I was
 compensating for my lack of familiarity.

 Nowadays, I tend to find it much more successful producing code that has a
 certain number of assumptions:
 - it will be maintained for far longer than it took to write (some of our
 apps are decades old)
 - readers will be competant wielders of the toolsets used
 - idiomatic code is strongly preferred, as are coding conventions
 - reader understands the problem domain and the solution domain

 Trying to write code that is somehow a training manual, a design  document
 etc. Is a hiding to nothing. The best communication tool I have found is
 regular discussions with the relevant people. Corporate mindshare is best
 maintained through words not code.

 I said before, and I think I it needs repeating as you asked again, but
 no, I dont think FP is any less concerned with the WHY or the HOW etc. I do
 think it uses seperate tools to achieve the same goals. I would claim that
 my code still satisfies all of the excellent points rsised in the best
 practices literature,  but Clojure doesn't require the same verbosity.

 As ever, this is only my opinion :).
 On 14 Dec 2014 07:34, Philip Schwarz 
 philip.johann.schw...@googlemail.com wrote:

 Hi Leif,

 if I compare your suggestion

 (let [top-right (create-top-right-quadrant-for letter)
right (stack top-right
   (flip top-right))
diamond (beside (map reverse (drop-first-col right)) right)]
   (display diamond))


 with mine

   (let [top-right-quadrant (create-top-right-quadrant-for letter)
 top-left-quadrant (drop-first-column-and-reverse-every-row-of
 top-right-quadrant)
 top-half-of-diamond (join-together-side-by-side top-left-quadrant
 top-right-quadrant)
 bottom-half-of-diamond (flip-bottom-up-and-drop-first-row-of
 top-half-of-diamond)
 diamond (put-one-on-top-of-the-other top-half-of-diamond
 bottom-half-of-diamond)]

 yours is more inviting, and mine just looks like a barrage of verbiage.

 But with some judicious spacing and syntax highlighting, I think mine
 regains IMHO its effectiveness

   (let [*top-right-quadrant  **(**create-top-right-quadrant-for *
 *letter**)*
 *top-left-quadrant  * *(*
 *drop-first-column-and-reverse-every-row-of* *top-right-quadrant**)*
 *top-half-of-diamond* *(**join-together-side-by-side*
 *top-left-quadrant *
 *
 top-right-quadrant**)*
 *bottom-half-of-diamond*  *(*
 *flip-bottom-up-and-drop-first-row-of* *top-half-of-diamond)*
 *diamond* *(*put-one-on-top-of-the-other
 *top-half-of-diamond*

 *bottom-half-of-diamond**)*]
 even better if I adopt the 'beside' you suggested, and its 'above'
 counterpart:

   (let [*top-right-quadrant  **(**create-top-right-quadrant-for *
 *letter**)*
 *top-left-quadrant  * *(*
 

Re: Charting Data Format Feedback Requested

[Lucas Bradstreet]

Hi Mike, Matt,

Some responses below.

On 12 December 2014 at 23:33, Matt Revelle mreve...@gmail.com wrote:
 I had started thinking about this problem recently too and also had broken
 it down to two parts. I was going to create a simple data frame protocol for
 a) and a ggplot2-inspired library which emits SVG for b). There is prior
 work for plotting in Incanter (using JFreeChart) and David Liebke also
 started a SVG-emitting plot library, Analemma
 (https://github.com/liebke/analemma). I believe there is some sort of data
 frame implementation in Incanter.

Thanks. I'll have a look at these. The data frame implementation in
core.matrix is currently quite similar to the incanter data frame
format. However we may find this format limiting, and therefore we're
looking into extending it to matrices with arbitrary dimensionality.
Thanks for the Analemma suggestion, I think some of the ideas will be
useful.


 My motivation was for simple libraries which could be used to generate
 well-designed figures. I frequently end up exporting data from Clojure to R
 only for ggplot2. Having a data frame is useful for designing the plotting
 API or quickly collecting aggregate statistics for certain attributes or
 factor levels.

That's unfortunate, and certainly part of what we are trying to avoid.
Our initial focus is on a clojurescript implementation of the charting
/ figure generation, however the point of the discussion is to ensure
that the charting format/data frame format would be usable from the
clojure/JVM side too.


 On Friday, December 12, 2014 4:29:37 AM UTC-5, Mike Anderson wrote:

 Lucas,

 Thanks for kicking off the discussion - great to see your proposal on
 this. I think it will be really valuable if we can converge on a standard
 way of representing this kind of data in Clojure/ClojureScript. Copying the
 Incanter and main Clojure groups as well because I think there will be broad
 interest in this.

 My view is that it is worth distinguishing (decomplecting?) two things:

 a) The format used to convey the actual data, i.e. the labelled :dataset
 part of the data format suggested below
 b) The format used to specify the chart (chart type, axes etc.)

 I think a) Can be pretty closely linked to the standard core.matrix
 dataset / n-dimensional array structure.

Agreed. We have attempted to follow a similar structure to the
core.matrix dataset implementation, however it looks like this will
prove limiting in the long run. Ideally core.matrix datasets will be
extended to support n-dimensional core.matrix matrices.


 b) is much harder and may call for something more like ggplot2, also worth
 checking out Kevin Lynagh's c2 work (https://keminglabs.com/c2/)

c2 is certainly interesting, though I haven't seen many examples of it
being used in more advanced visualisations. It may be better to wrap
d3 in a more declarative way, though based on our experiences thus far
we may end up fighting between the two models. On the plus side, d3 is
far more battle-tested. Our experience in wrapping d3 based charting
libraries like C3 and Dimple with the OM component model has proven to
be an excellent experience so far. Updates to these charts are only
triggered when data changes, and are handled internally by d3's update
model. However, once if we need to venture outside of these charting
libraries for any other visualisation needs, then we're back to
writing d3 code.


 Therefore it may be easier to tackle a) in isolation first. b) will
 probably need more experimentation before we can settle on something
 sufficiently well designed and general.

I agree that the data frame/set spec is definitely the place to start.

Cheers


 On Thursday, 11 December 2014 17:45:00 UTC+8, Lucas Bradstreet wrote:

 Hi everyone,

 We are currently writing an OM based visualisation / charting library
 that we
 intend to use extensively in combination with core.matrix and other data
 analysis libraries/tools (e.g. gorilla REPL, incanter, etc).

 Some of the goals of this library:
 - Provide a clojurescript wrapper for common visualisation libraries (C3,
   dimple, Rickshaw, NVD3) for standard charting features.
 - Provide a generic data format, with conversion functions to native
 charting
   library formats.
 - Provide transformation functions between core.matrix datasets, incanter
   datasets, etc to this generic charting format.
 - Provide update functions to allow datasets to seamlessly be updated
 with the
   addition of data-points in map and vector formats.
 - Provide seamless transitions when a dataset is updated, ala om.

 We would like to hear any of your thoughts regarding the following
 charting
 data format below. This format maps fairly closely to core.matrix
 datasets
 (note, although core.matrix datasets currently do not allow labelled
 dimensions, this support is incoming).

 {:axes [{:label X axis label :type :category}
 {:label Y axis label :type :category}
 {:label Z axis label :type :measure}
 {:label C axis label 

Re: Charting Data Format Feedback Requested

[Lucas Bradstreet]

Hi Jony,

I'm a fan of Gorilla REPL. I'd love to have this work supported with
it. Is it easy to support Clojurescript based renderers within
GorillaREPL? It would be nice to support interactive figures with this
kind of use case (in addition to SVG based plots, of course).

From the responses thus far, it appears that ggplot is the gold
standard for composable, customizable charts. Once we get the
dataframe format right, I'll invest some time into learning what I can
from it. We certainly want any implementation to be as data driven as
possible.

Thanks,

Lucas


On 13 December 2014 at 22:42, Jony Hudson jonyepsi...@gmail.com wrote:
 I think it would be great, and a very useful contribution to the Clojure
 world, to have a flexible plotting library. My perspective, at risk of going
 a bit off-topic, and from the biased position of a Gorilla REPL author ...


 When I think about the sort of programming I do as a scientist - data
 analysis, modelling, numerics, statistics - I have a few requirements:


 - For me, having a notebook interface is essential. It's how I think. It's
 the interactivity of the REPL, plus rich output, plus note-taking.

 - I'd like to write my code in a civilised language. Ideally one that puts
 data first, because that's at the heart of the problems I solve.

 - I want to be able to make things run fast when I need to. So I need some
 ability to write low-level code on occasion.

 - I'd rather not re-write the whole world, so libraries are good.

 - I want to be able to plot things the way I want them.


 If I think about the possible contenders, written as (Notebook interface,
 language, low-level language escape hatch) then the ones I'm familiar with,
 and are advanced enough to use day-to-day for work, are:


 (Gorilla REPL, Clojure, Java)

 (IPython, Python, C)

 (R, R, C)

 (Mathematica notebook, Wolfram language,
 sort-of-C/sort-of-Java/sort-of-.NET)


 In terms of the interface, obviously Gorilla REPL is the best of the bunch
 :-) From a language perspective, my opinion is Clojure/Java wins this
 hands-down. Preaching to the choir here, but Clojure is great for
 data-oriented programming, and importantly for me, it's _really_ easy to
 drop into Java when it matters. Library-wise, all are strong. Each has their
 own advantages, but I'd say the Clojure/Java ecosystem has enough that, for
 what I do, I rarely get stuck. For plotting Mathematica and R are leagues
 ahead. I'm not familiar with the latest developments in Python, but last I
 looked I didn’t see anything doing it the way I think it should be done.


 Which, brings me to why I’m sharing all of this unsolicited opinion … it’s
 because I think a really strong plotting library would position Clojure
 alongside the very best environments to do science and technical
 computing/data science (or whatever it is we’re calling “thinking about data
 with a computer” these days). Gorilla/Clojure works great for me, but I do
 fire up R and Mathematica frequently for more advanced plotting. So, a
 full-featured plot library is something I’d love to see happen, and would be
 interested in working towards.


 In terms of what such a library would look like, while there’s value in
 debating the best way to do it, there’s also value in copying the best
 that’s out there! So I agree with Matt that a ggplot2-alike emitting SVG is
 a good thing to start with. ggplot2 does a great job of making plots
 composable, easily customised etc. And SVG can be rendered to anything, and
 Gorilla supports it natively. The key point, to my mind, would be how to
 make the ggplot API more data-driven, rather than the OO approach that it
 takes.


 So, to summarise my ramble: I think this would be great, and it’s something
 I’d like to be involved with. I’d been planning to give some thought to just
 this after the end of term. Although, I don’t know how that will work out,
 realistically … if everyone on this list manages to do what they’re planning
 to do over the holiday break then January will be a golden age of Clojure!



 Jony

 --
 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
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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 

Re: what do you think about this code?

[Andy Dwelly]

I'm somewhat late to the party, but what the hey - it's a quiet Sunday 
afternoon, and for my own amusement I came up with:

(defn spaces [n] (apply str (take n (repeat .

(defn n-a [n] (char (+ n (int \A

(defn a-n [a] (- (int a) (int \A)))

(defn gap [n] (spaces (dec (* 2 n

(defn diamond [c]
  (let [l (a-n c)]
(when (= (a-n \A) l (a-n \Z))
  (doseq [i (range l)] (println (str (spaces (- l i)) (n-a i) (gap i) 
(when-not (zero? i) (n-a i)
  (println (str c (spaces (dec (* 2 l))) (when-not (= \A c
  (doseq [i (reverse (range l))] (println (str (spaces (- l i)) (n-a 
i) (gap i) (when-not (zero? i) (n-a i
   
Normally I'd add a few comments to this code , especially the diamond 
function - which is at the limit of the density I feel comfortable with. 
That said - it seems to work.

What I find interesting about this is the length of the code compared with 
the various Java solutions I looked at; looks like Paul Graham was right:

http://www.paulgraham.com/power.html

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: what do you think about this code?

[Philip Schwarz]

Hi David

In fact, at this point I prefer using Prismatic's schema (
https://github.com/Prismatic/schema 
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPrismatic%2Fschemasa=Dsntz=1usg=AFQjCNFIdJn-v4ShLockO3sVBrwopRZiOQ)
 
to document as well as provide further safety for my functions
goes on my todo list

Philip

On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote:

 Hi Philip,

 I read your message and immediately wanted to try it myself--I intended to 
 leave it at that but I realized I would be remiss if I did not give you a 
 little bit of feedback based on my experience.  I should add that I was 
 kind of fast and loose with my solution (that is, I didn't really read the 
 instructions), but it does print out the diamond shape according to what I 
 saw in the blog post examples.

 First of all, here's what I came up with:

 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 As you said, you weren't looking for alternative algorithms and I 
 recognize that that's not the point.  But there are a few things that I 
 think are good and/or common Clojure practice that I think I've 
 internalized, and writing out an alternative solution helped me to see them.

 - I'm assuming you used a TDD process to write this (correct me if 
 wrong--basing that on the articles you linked to), but I think a 
 repl-driven process may be more common for working through a problem like 
 this--i.e. something you can wrap your head around as a whole and solve 
 iteratively.  That's not to say I and others don't use TDD in Clojure dev, 
 but just that it's also quite common to do a lot of this kind of 
 development in the repl.

 - you're grouping your side-effecting code w/the code that generates the 
 diamond data structure here: 
 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 While of course the diamond kata is a bit contrived and the point is to 
 print stuff out in the end, it also looks like you are trying to be 
 thoughtful about how you structure your code.  So I would suggest isolating 
 your pure functions from your side-effecting code as a sort of basic 
 separation, and avoid monolithic functions like the one I linked to above.  
 This gives you the freedom to apply the data structure to other processes 
 if need be, rather than having to refactor that code later on as soon as 
 you need to do something other than printing to the final diamond data 
 structure.  That is a more compositional approach that is good to follow as 
 part of functional programming practice in general.  And otherwise it seems 
 like you are following this approach--I think you can see this in the shape 
 of your code overall.

 - Stylistically, I found your naming conventions to be too verbose, with 
 not enough information about the actual input and output--I would prefer a 
 style like I used in my solution which aims for readable conciseness, while 
 documenting what is going in and coming out of my functions.  I assume 
 Clojure developers reading my code will have a good understanding of the 
 core data structures and functions available to manipulate them, and so I 
 want to leverage that as much as possible in how I write and document my 
 code.

 In fact, at this point I prefer using Prismatic's schema (
 https://github.com/Prismatic/schema) to document as well as provide 
 further safety for my functions, and am of the opinion that Clojure's one 
 glaring weakness is its approach to typing--but that's another discussion 
 and I recognize this is not necessarily a widely-held opinion.

 More generally, I think reasonable people could disagree on naming 
 conventions and so I would hesitate to say you're doing something wrong 
 here--I would rather say: the more Clojure code you read the more you'll 
 get a sense of how people tend to write.  You'll figure out what you want 
 to adopt in your own style, and what Clojure devs are going to expect.

 - I don't want to get too deep into the algorithm itself but I think you 
 would find it more natural to work line by line vs. the way you constructed 
 blocks and flipped them right/left, and you'd have less code overall.  I 
 will boldly claim that my solution may be closer to how other developers 
 familiar with Clojure (or functional programming in general) may approach 
 it--not that I'm claiming it's the best approach.  I do think it is more 
 concise without sacrificing readability (which is subjective, I fully 
 appreciate).

 - I don't know if I've ever once used a main function, and you don't see 
 them in libraries, certainly.  But that is minor--there's no reason *not* 
 to use it, just that I wouldn't expect to see it.

 I hope this is useful feedback--good luck in your journey and enjoy 
 Clojure!

 Dave


 2014-12-06 19:48 GMT+09:00 Philip Schwarz philip.joh...@googlemail.com 
 javascript::

 Hello,

 can you please review my first solution to the diamond kata [1] and tear 
 it to bits: let me know all the ways in which YOU would 

Re: what do you think about this code?

[Philip Schwarz]

David,

- I don't know if I've ever once used a main function, and you don't see 
them in libraries, certainly.  But that is minor--there's no reason *not* 
to use it, just that I wouldn't expect to see it.
I was influenced by the following passage in Web Development with Clojure: 
Build Bulletproof Web Apps with Less Code 
https://pragprog.com/book/dswdcloj/web-development-with-clojure:

The project.clj file will allow us to manage many different aspects of our 
application, as well. For example, we could set the foo function from the 
myapp.core namespace as the entry point for the application using the *:main 
*key:

(defproject myapp 0.1.0-SNAPSHOT

:description FIXME: write description

:url http://example.com/FIXME;

:license {:name Eclipse Public License

:url http://www.eclipse.org/legal/epl-v10.html}

:dependencies [[org.clojure/clojure 1.6.0]]

;;this will set foo as the main function

*:main *myapp.core/foo)

The application can now be run from the command line using lein run.

In Java, the entry point to an application is called main, so I thought if 
the lein entry point for an application is labelled main, and I am in a 
hurry to get on with the meat of the diamond kata, I'll just call it main 
for now, and improve it later. But as Kent Beck says: later means never ;-)

Philip

On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote:

 Hi Philip,

 I read your message and immediately wanted to try it myself--I intended to 
 leave it at that but I realized I would be remiss if I did not give you a 
 little bit of feedback based on my experience.  I should add that I was 
 kind of fast and loose with my solution (that is, I didn't really read the 
 instructions), but it does print out the diamond shape according to what I 
 saw in the blog post examples.

 First of all, here's what I came up with:

 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 As you said, you weren't looking for alternative algorithms and I 
 recognize that that's not the point.  But there are a few things that I 
 think are good and/or common Clojure practice that I think I've 
 internalized, and writing out an alternative solution helped me to see them.

 - I'm assuming you used a TDD process to write this (correct me if 
 wrong--basing that on the articles you linked to), but I think a 
 repl-driven process may be more common for working through a problem like 
 this--i.e. something you can wrap your head around as a whole and solve 
 iteratively.  That's not to say I and others don't use TDD in Clojure dev, 
 but just that it's also quite common to do a lot of this kind of 
 development in the repl.

 - you're grouping your side-effecting code w/the code that generates the 
 diamond data structure here: 
 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 While of course the diamond kata is a bit contrived and the point is to 
 print stuff out in the end, it also looks like you are trying to be 
 thoughtful about how you structure your code.  So I would suggest isolating 
 your pure functions from your side-effecting code as a sort of basic 
 separation, and avoid monolithic functions like the one I linked to above.  
 This gives you the freedom to apply the data structure to other processes 
 if need be, rather than having to refactor that code later on as soon as 
 you need to do something other than printing to the final diamond data 
 structure.  That is a more compositional approach that is good to follow as 
 part of functional programming practice in general.  And otherwise it seems 
 like you are following this approach--I think you can see this in the shape 
 of your code overall.

 - Stylistically, I found your naming conventions to be too verbose, with 
 not enough information about the actual input and output--I would prefer a 
 style like I used in my solution which aims for readable conciseness, while 
 documenting what is going in and coming out of my functions.  I assume 
 Clojure developers reading my code will have a good understanding of the 
 core data structures and functions available to manipulate them, and so I 
 want to leverage that as much as possible in how I write and document my 
 code.

 In fact, at this point I prefer using Prismatic's schema (
 https://github.com/Prismatic/schema) to document as well as provide 
 further safety for my functions, and am of the opinion that Clojure's one 
 glaring weakness is its approach to typing--but that's another discussion 
 and I recognize this is not necessarily a widely-held opinion.

 More generally, I think reasonable people could disagree on naming 
 conventions and so I would hesitate to say you're doing something wrong 
 here--I would rather say: the more Clojure code you read the more you'll 
 get a sense of how people tend to write.  You'll figure out what you want 
 to adopt in your own style, and what Clojure devs are going to expect.

 - I don't want to get too deep into the algorithm itself but I think you 

Re: what do you think about this code?

[Philip Schwarz]

David,

More generally, I think reasonable people could disagree on naming 
conventions
yes, and on what constitutes clean code, too. I like the viewpoint Robert 
Martin's offers us in his book Clean Code 
http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882.
 
Here is my own super-short summary:

   - What is clean code? 
   - There are probably as many definitions as there are programmers.
   - Martial artists do not all agree about the best martial art, or the 
   best technique within a martial art. 
   - There are various 'Schools of Thought'
   - None of them is absolutely right.
   - But within each School, the teachings and techniques are treated as 
   being right, being absolutes
   - Over time students may immerse themselves in the teachings of 
   different masters, to broaden their knowledge and practice
   - At some point they may even found their own school 
   
The Clean Code book is Martin's School of Clean Code. It describes the 
School’s values, principles, practices, patterns, heuristics, etc.

Are there books describing functional programming schools of thought?

Philip 


On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote:

 Hi Philip,

 I read your message and immediately wanted to try it myself--I intended to 
 leave it at that but I realized I would be remiss if I did not give you a 
 little bit of feedback based on my experience.  I should add that I was 
 kind of fast and loose with my solution (that is, I didn't really read the 
 instructions), but it does print out the diamond shape according to what I 
 saw in the blog post examples.

 First of all, here's what I came up with:

 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 As you said, you weren't looking for alternative algorithms and I 
 recognize that that's not the point.  But there are a few things that I 
 think are good and/or common Clojure practice that I think I've 
 internalized, and writing out an alternative solution helped me to see them.

 - I'm assuming you used a TDD process to write this (correct me if 
 wrong--basing that on the articles you linked to), but I think a 
 repl-driven process may be more common for working through a problem like 
 this--i.e. something you can wrap your head around as a whole and solve 
 iteratively.  That's not to say I and others don't use TDD in Clojure dev, 
 but just that it's also quite common to do a lot of this kind of 
 development in the repl.

 - you're grouping your side-effecting code w/the code that generates the 
 diamond data structure here: 
 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 While of course the diamond kata is a bit contrived and the point is to 
 print stuff out in the end, it also looks like you are trying to be 
 thoughtful about how you structure your code.  So I would suggest isolating 
 your pure functions from your side-effecting code as a sort of basic 
 separation, and avoid monolithic functions like the one I linked to above.  
 This gives you the freedom to apply the data structure to other processes 
 if need be, rather than having to refactor that code later on as soon as 
 you need to do something other than printing to the final diamond data 
 structure.  That is a more compositional approach that is good to follow as 
 part of functional programming practice in general.  And otherwise it seems 
 like you are following this approach--I think you can see this in the shape 
 of your code overall.

 - Stylistically, I found your naming conventions to be too verbose, with 
 not enough information about the actual input and output--I would prefer a 
 style like I used in my solution which aims for readable conciseness, while 
 documenting what is going in and coming out of my functions.  I assume 
 Clojure developers reading my code will have a good understanding of the 
 core data structures and functions available to manipulate them, and so I 
 want to leverage that as much as possible in how I write and document my 
 code.

 In fact, at this point I prefer using Prismatic's schema (
 https://github.com/Prismatic/schema) to document as well as provide 
 further safety for my functions, and am of the opinion that Clojure's one 
 glaring weakness is its approach to typing--but that's another discussion 
 and I recognize this is not necessarily a widely-held opinion.

 More generally, I think reasonable people could disagree on naming 
 conventions and so I would hesitate to say you're doing something wrong 
 here--I would rather say: the more Clojure code you read the more you'll 
 get a sense of how people tend to write.  You'll figure out what you want 
 to adopt in your own style, and what Clojure devs are going to expect.

 - I don't want to get too deep into the algorithm itself but I think you 
 would find it more natural to work line by line vs. the way you constructed 
 blocks and flipped them right/left, and you'd have less code overall.  I 
 will boldly claim 

Re: what do you think about this code?

[Philip Schwarz]

Hi Colin,

Clojure code tends to be much more about the shape of transformations than 
the semantics of those transformations.
Interesting, thanks

I think most people would inline that. Extracting it however, give helpful 
information about the structure which isn't captured by the call to concat, 
namely the vertical nature (top/bottom). 
Of course, if the variable names were retained then is also sufficient but 
they almost certainly wouldn't be.
Yes

I am on the fence, and fall down frequently either side (you wouldn't 
believe the chaffing :)) -
Yes, I may soon be in the same position

But I also *feel the loss of the info captured in variable names/function 
names* as well. 
Yes

the more Clojure you write the more you start to realise that the same 
shapes of functions come up time and time again - the structural shape of 
the code imparts knowledge sometimes.
OK

Philip

On Saturday, 6 December 2014 18:40:16 UTC, Colin Yates wrote:

 Excellent question and I will be watching this thread with interest.

 Similar to David Della Costa, I find a bit difference between Clojure and 
 Java for example is that there is much less naming-of-concepts. Clojure 
 code tends to be much more about the shape of transformations than the 
 semantics of those transformations.

 A case in point, you wrote [code](defn put-one-on-top-of-the-other 
 [top-half-of-diamond bottom-half-of-diamond] (concat top-half-of-diamond 
 bottom-half-of-diamond))[/code]. I think most people would inline that. 
 Extracting it however, give helpful information about the structure which 
 isn't captured by the call to concat, namely the vertical nature 
 (top/bottom). Of course, if the variable names were retained then is also 
 sufficient but they almost certainly wouldn't be.

 I am on the fence, and fall down frequently either side (you wouldn't 
 believe the chaffing :)) - the more Clojure I write the more comfortable I 
 am with dense calls to core.clj functions. But I also feel the loss of the 
 info captured in variable names/function names as well. 

 Another point worth mentioning is that the more Clojure you write the more 
 you start to realise that the same shapes of functions come up time and 
 time again - the structural shape of the code imparts knowledge sometimes.

 As David says, if you haven't looked at Prismatic Schema then have a look. 
 I find the definition of the schema is also an excellent place to capture 
 this extra layer of info in the names of those structures.

 Good question.

 On Saturday, 6 December 2014 10:48:02 UTC, Philip Schwarz wrote:

 Hello,

 can you please review my first solution to the diamond kata [1] and tear 
 it to bits: let me know all the ways in which YOU would improve the code.

 I am not so interested in a better algorithm for solving the kata. I am 
 learning Clojure and what I want to know is what YOU would do to make the 
 code more readable/understandable/maintainable, or just to make it follow 
 Clojure idioms and/or conventions that YOU find effective, or to follow a 
 coding style that YOU find more effective.

 Thanks,

 Philip

 [1] https://github.com/philipschwarz/diamond-problem-in-clojure



-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: what do you think about this code?

[Philip Schwarz]

Hi Leif,

You have the idea of a palindrome in your solution: neat!

Philip 

On Tuesday, 9 December 2014 05:06:22 UTC, Leif wrote:

 Hi, Philip.

 I had the same urge as David--I tried it out, glossing over any formal 
 rules.  Here's what I came up with:
 https://gist.github.com/leifp/ae37c3b6f1b497f13f1e

 In truth, I think David's solution is more readable and maintainable.  But 
 I think maintainability is a pretty tricky concept:

 My code makes a seq of maps describing rows, and then turns them into 
 strings at the end.  This is probably more work to understand than David's 
 solution.  But is it less maintainable?  Well, currently, the answer is 
 yes, but what if I need to output a diamond in several different 
 formats?  What if marketing wants each row to be a different color and 
 font?  I would start to favor my solution in that case.  My point is that 
 the difference between maintainable and horrible is evident, but the 
 difference between maintainable and easily maintainable depends on 
 predicting the future somewhat.

 I also favor a slightly less verbose style.  A function is an abstraction, 
 and you seem to be writing functions for very concrete steps. I think you 
 have most of the correct abstractions for your solution method, you just 
 need to consolidate the more concrete steps.  Something like:

 flip-bottom-up - flip (or vertical- and horizontal-flip)
 join-together-side-by-side - beside
 put-one-on-top-of-the-other - stack (or ontop, or ...)
 reverse-every-row - (map reverse rows) ; very readable to clojure 
 programmers

 (let [top-right (create-top-right-quadrant-for letter)
right (stack top-right
   (flip top-right))
diamond (beside (map reverse (drop-first-col right)) right)]
   (display diamond))

 The broad takeaway is: if I write a function I only use once, I usually 
 just inline it.  Unless of course I believe deep in my heart I'll have need 
 of it somewhere else soon :).  
 This is somewhat a matter of taste, and again, the requirements history 
 usually determines what gets abstracted into functions, and history can be 
 messy. :)

 Hope that helps,
 Leif

 On Saturday, December 6, 2014 5:48:02 AM UTC-5, Philip Schwarz wrote:

 Hello,

 can you please review my first solution to the diamond kata [1] and tear 
 it to bits: let me know all the ways in which YOU would improve the code.

 I am not so interested in a better algorithm for solving the kata. I am 
 learning Clojure and what I want to know is what YOU would do to make the 
 code more readable/understandable/maintainable, or just to make it follow 
 Clojure idioms and/or conventions that YOU find effective, or to follow a 
 coding style that YOU find more effective.

 Thanks,

 Philip

 [1] https://github.com/philipschwarz/diamond-problem-in-clojure



-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: what do you think about this code?

[Philip Schwarz]

thanks

On Tuesday, 9 December 2014 08:01:58 UTC, Colin Yates wrote:

 I forgot to mention but https://github.com/bbatsov/clojure-style-guide is 
 a pretty good resource.
 On 9 Dec 2014 00:24, Philip Schwarz philip.joh...@googlemail.com 
 javascript: wrote:

 Hello David,

 I had set myself the constraint that I wanted the solution to exploit two 
 symmetries: 
 (1) The top left and top right of the diamond are mirror images
 (2) The top half and bottom half of the diamond are also mirror images

 I'm assuming you used a TDD process to write this (correct me if 
 wrong--basing that on the articles you linked to)
 I was on a train commuting back home, and what I did was sit in a loop 
 where I wrote some code and then tweaked it until executing it in the REPL 
 gave me the part of the diamond that I wanted, by eyeballing the console 
 output. What a coincidence that in your gist you linked to 
 http://blog.jayfields.com/2014/01/repl-driven-development.html . I was 
 looking at exactly that blog post on Sunday to determine if what I had been 
 doing could be classified as REPL-based? Still not sure. Thoughts?

 My first version of the code was this 
 https://gist.github.com/philipschwarz/c7e3be1ac97e482d04bf: 

 (defn print-diamond [letter]
   (let [alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ
 position-of (fn [letter] (inc (- (int letter) (int \A
 number-of-letters (position-of letter)
 dashes (fn [n] (repeat n \-))
 fixed-text-for (fn [letter] (concat (dashes (dec (position-of 
 letter))) (list letter)))
 template (map fixed-text-for (take number-of-letters alphabet))
 pad-with-trailing-dashes (fn [index line] (concat line (dashes (dec 
 (- number-of-letters index)
 top-right-quadrant (map-indexed pad-with-trailing-dashes template)
 top-left-quadrant (map reverse (map rest (take number-of-letters 
 top-right-quadrant)))
 top-half (map concat top-left-quadrant top-right-quadrant)
 diamond (concat top-half (drop 1 (reverse top-half)))]
 (doseq [line (map #(apply str %) diamond)]
   (println line

 I showed it to Extreme Programming and Agile Guru Ron Jeffries, and the 
 following conversation ensued:


 @philip_schwarz 1st stab at Clojure print-diamond using symmetries 
 identified by @TotherAlistair @RonJeffries @gdinwiddie @sebrose 
 https://gist.github.com/philipschwarz/c7e3be1ac97e482d04bf 
 @RonJeffries @philip_schwarz *can people read that and figure out what 
 it does? *i can't but not a closure person. @totheralistair @gdinwiddie 
 @sebrose
 @philip_schwarz @RonJeffries @TotherAlistair @gdinwiddie @sebrose *I 
 like defns of top-half  diamond  think they r graspable-ish; 
 top-left-quadrant less so*
 @philip_schwarz one interesting Q for us all is *if one didn't know the 
 prob could one grok the prog* @totheralistair @gdinwiddie @sebrose
 @gdinwiddie .@RonJeffries I think *the program is generally easier to 
 grok if you've got the tests, too.* @philip_schwarz @TotherAlistair 
 @sebrose
 @philip_schwarz  Dec 3
 @gdinwiddie @RonJeffries @TotherAlistair @sebrose agree - I have added 
 tests: 
 https://github.com/philipschwarz/diamond-problem-in-clojure/blob/master/test/diamond_problem_in_clojure/core_test.clj
  

 I notice you did not write tests. I also notice that you added comments 
 to your methods. I like your comments. Find them useful. I am not saying 
 the following applies to your comments, but it will give you an idea of the 
 programming culture I am part of. In that culture, comments are looked at 
 with suspicion:
 e.g. 1: https://twitter.com/nzkoz/status/538892801941848064

 https://pbs.twimg.com/media/B3qIJLFCcAEJLWm.jpg

 e.g. 2: The proper use of comments is to compensate for our failure to 
 express ourself in code. - Robert C. Martin
 e.g. 3: Comments often are used as a deodorant... often comments are 
 there because the code is bad. - Martin Fowler
 e.g. 4: 

- Primary Rule: Comments are for things that *cannot* be expressed in 
code.
- Redundancy Rule: Comments which restate code must be deleted.
- Single Truth Rule: If the comment says what the code *could* say, 
then the code must change to make the comment redundant.


 In that culture, we aim to use certain implementation patterns that make 
 comments unnecessary. Also, where possible, the tests act as (executable, 
 more reliable) documentation.

 Moving on, after writing the terse first version of the code, I set out 
 to *make my code more readable*.

 Are you familiar with Robert Martin's dictum?: 

 The Three Functions of a s/w module:
 * The function it performs while executing
 * To afford change. A module that is difficult to change is broken and 
 needs fixing, even though it works
 * *To communicate to its readers. A module that does not communicate is 
 broken and needs fixing.*

 The rationale for making code more readable is an economic one. Here is a 
 brief summary of Ken't Beck's thoughts on the 

Re: tools.namespace ns parsing

[Andy Fingerhut]

I have just been working for the last day on adding code to the Eastwood
Clojure lint tool [1] for checking these and a few other things about wrong
ns forms.  The documentation I just wrote for what it will do is here [2].

No released version of Eastwood makes these checks yet.  I will probably
release the first Eastwood version that does within the next 1 to 3 weeks.
There are instructions in Eastwood's documentation for using the latest
unreleased version if you are interested on being on the bleeding edge [3].

If anyone has thoughts on other things to warn about in wrong ns forms,
please reply to this thread, or create an Eastwood issue on GitHub.  The
only other change I have in mind right now is perhaps not warning if
someone uses :include-macros in :require, because it appears that has snuck
into the :require's of several projects that are both Clojure/Java and
ClojureScript.  I will first verify that this option is ignored by
Clojure/Java before eliminating such warnings.

Andy


[1] https://github.com/jonase/eastwood
[2]
https://github.com/jonase/eastwood/blob/master/README.next.md#wrong-ns-form
[3] https://github.com/jonase/eastwood#for-eastwood-developers


On Sun, Dec 14, 2014 at 1:58 AM, Petr petrg...@gmail.com wrote:

   Hello.

  I stumbled on a problem that caused me fair amount of frustration and I
 suspect that it could affect other users who start using tools.namespace.

 The problem is that clojure.code/ns macro is more lenient than what
 follows from it’s documentation. For example ‘use’ (or require) clause in
 vector is accepted e.g. “[:use ]” (see
 http://dev.clojure.org/jira/browse/TNS-21) or use clause with plain
 symbol (not keyword) is also OK, e.g. “(use ) (as in my case
 http://dev.clojure.org/jira/browse/TNS-30). And the way ns macro is
 expanded section in form “( )” would be replaced with
 “(clojure.core/ ... )”. However tools.namespace parses dependencies
 strictly according to doc. E.g.TNS-21 was closed as won’t fix for that
 reason.

  This way there could be ns declarations  that have no compilation errors
 and work as one may think but are ignored by c.t.n’s parser.  Hence there
 could be actual dependencies that are silently ignored without any error or
 warning.

  It seems that proper way to resolve this would be to rewrite ns macro to
 be more strict and accept only what’s described in documentation. But I
 suspect that this would lead to backward compatibility issues - some of
 existing code will break.

  There is also possibility to rewrite
 clojure.tools.namespace.parse/deps-from-ns-decl so it does macroexpand and
 then looks for references to clojure.core/refer, clojure.core/require and
 clojure.core/use. This would match now ns actually works but one might not
 like this “implementation as specification”.

  So I think that the good solution for now would be to have some
 validation function forns form. This function would issue a warning when
 some parts of namespace declaration could be ignored. This way unexpected
 behavior of clojure.tools.namespace.repl/refresh would not go unnoticed and
 this will make this library more user-friendly.

 What do you think would be a good solution for this?


  --
 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
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: what do you think about this code?

[Philip Schwarz]

Hi Leif,

what if I need to output a diamond in several different formats?  What if 
marketing wants each row to be a different color and font?  I would start 
to favor my solution in that case. 
...the difference between maintainable and easily maintainable depends 
on predicting the future somewhat.
There are interesting views on the subject in Agile and Extreme 
Programming.  

Have you heard of Extreme Programming's YAGNI principle: You Ain't Gonna 
Need It http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

In Refactoring 
http://www.informit.com/articles/article.aspx?p=1400866seqNum=13, Martin 
Fowler has a code smell called *Speculative Generality*:

You get it when people say, Oh, I think we need the ability to this kind 
 of thing someday and thus want all sorts of hooks and special cases to 
 handle things that aren't required. The result often is harder to 
 understand and maintain. If all this machinery were being used, it would be 
 worth it. But if it isn't, it isn't. The machinery just gets in the way, so 
 get rid of it.


In ASD:PPP 
http://www.amazon.co.uk/Software-Development-Principles-Patterns-Practices/dp/0132760584
 
Robert Martin has a Design Smell called *Needless Complexity*
 

 A design smells of needless complexity when it contains elements that 
 aren't currently useful. This frequently happens when developers anticipate 
 changes to the requirements and put facilities in the software to deal with 
 those potential changes. At first, this may seem like a good thing to do. 
 After all, preparing for future changes should keep our code flexible and 
 prevent nightmarish changes later.

 Unfortunately, the effect is often just the opposite. By preparing for 
 many contingencies, the design becomes littered with constructs that are 
 never used. Some of those preparations may pay off, but many more do not. 
 Meanwhile, the design carries the weight of these unused design elements. 
 This makes the software complex and difficult to understand.


I already mentioned elsewhere in the thread that according to Kent Beck, 

   - cost(total) = cost(develop) + cost(maintain) 
   - cost(maintain) = cost(understand) + cost(change) + cost(test) + 
   cost(deploy)
   - learning what the current code does is the expensive part

So his strategy for reducing overall costs is to *ask all programmers to 
address the cost of understanding code during the maintenance phase by 
focusing on communicating, programmer-to-programmer, i.e. writing clear 
code.*

Those ideas are from Implementation Patterns 
http://www.amazon.co.uk/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091.
 
In the same book Beck has has an interesting section on flexibility:

...flexibility is the justification used for the most ineffective coding 
 and design practices. e.g. ... Why all the complexity? Flexibility. 
 Programs should be flexible, but only in ways they change. If ... never 
 changes, all that complexity is cost without benefit.

 Since most of the cost of a program will be incurred after it is first 
 deployed, programs should be easy to change. *The flexibility I imagine 
 will be needed tomorrow, though, is likely to be not what I need when I 
 change the code*. That's why *the flexibility of simplicity and extensive 
 tests is more effective than the flexibility offered by speculative design.*

 *Choose patterns that encourage flexibility and bring immediate benefits. 
 For patterns with immediate costs and only deferred benefits, often 
 patience is the best strategy.* Put them back in the bag until they are 
 needed. Then you can apply them in precisely the way they are needed.

 Flexibility can come at the cost of increased complexity. For instance, 
 ... Simplicity can encourage flexibility. In the above example, if you can 
 find a way to eliminate ... without losing value, you will have a program 
 that is easier to change later.

 *Enhancing the communicability of software also adds to flexibility. The 
 more people who can quickly read, understand, and modify the code, the more 
 options your organization has for future change.*


The patterns in Beck's book encourage flexibility by helping programmers 
create simple, understandable applications that can be changed

Philip 

On Tuesday, 9 December 2014 05:06:22 UTC, Leif wrote:

 Hi, Philip.

 I had the same urge as David--I tried it out, glossing over any formal 
 rules.  Here's what I came up with:
 https://gist.github.com/leifp/ae37c3b6f1b497f13f1e

 In truth, I think David's solution is more readable and maintainable.  But 
 I think maintainability is a pretty tricky concept:

 My code makes a seq of maps describing rows, and then turns them into 
 strings at the end.  This is probably more work to understand than David's 
 solution.  But is it less maintainable?  Well, currently, the answer is 
 yes, but what if I need to output a diamond in several different 
 formats?  What if marketing wants each row to be a different 

Implementing a Oauth2 provider with clauth and friend

[Sebastian Bensusan]

Hi,

I am writing a Single Page Application using Om that communicates via XHR 
with a REST API using compojure + liberator. I should be able to 
authenticate users by using email  password credentials or third party 
Oauth2 like Linkedin's. I

My plan is: use clauth [1] to roll my own oauth2, package it as a friend 
credential-fn/workflow, and then wrap the liberator api with friend [2]  and 
the third parties workflows.

Anybody has any pointers on how to do this? It is a complex solution but I 
have no ideas on how to simplify it. 

Thanks for your time!

Sebastian

[1] https://github.com/pelle/clauth
[2] 
http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Has the old invalid constant tag: -57 bug been fixed?

[Alex Miller]

If you could refer to a ticket, an example, or really any other information, 
that might be a question I could answer. It doesn't ring a bell.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Has the old invalid constant tag: -57 bug been fixed?

[Andy Fingerhut]

Searching for unknown constant tag in the Clojure Google group finds a
few conversation threads mentioning it from several years ago.  I don't
recall any tickets for it.  From reading some of the discussion threads, it
sounds like there may never have been a cause identified.  Also, perhaps
occurrences of the problem could be eliminated by cleaning any existing
.class files and recompiling from scratch.

Andy

On Sun, Dec 14, 2014 at 11:18 AM, Alex Miller a...@puredanger.com wrote:

 If you could refer to a ticket, an example, or really any other
 information, that might be a question I could answer. It doesn't ring a
 bell.

 --
 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
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Charting Data Format Feedback Requested

[Jony Hudson]

Hi Lucas,

 I think, regarding integration with Gorilla, the real decision to be made 
is around interactivity. For non-interactive charts, it would be ideal to 
separate out the code that generates the chart from the code that messes 
with the DOM. Gorilla would then just use the charting code, and do its own 
DOM manipulation. It would probably also be ideal if the charting code ran 
server-side (CLJ) for Gorilla's purposes.

It sounds, though, that this is probably not the goal for your library. If 
you are aiming to build something that can handle interactive 
visualisations, and handle changing data, then I guess there's going to be 
much more interaction between the charting code and the DOM manipulation 
code. I'm not sure how that would fit in with Gorilla - but as a general 
design point (which would also ease Gorilla integration) there might be 
some value in making the interface between charting and DOM 
manipulation explicit, so that it is possible to plug in different 
approaches to DOM manipulation. That's not to say that this is 
realistically possible, just that I'd put it on the wishlist :-)

My current plan with Gorilla was to steer clear of interactivity, for two 
reasons: one, that for the sort of stuff I do myself, it's not really that 
useful (or, as I've said before: the interactivity you already get at the 
REPL is plenty); and two, because it looks like it's really, _really_ hard 
to get right! That said ... I recognise that people do do things that would 
be improved by interactivity, so if it is possible to make it work cleanly, 
then it is something I'd be keen to support in Gorilla :-)


Jony

On Sunday, 14 December 2014 12:26:17 UTC, Lucas Bradstreet wrote:

 Hi Jony, 

 I'm a fan of Gorilla REPL. I'd love to have this work supported with 
 it. Is it easy to support Clojurescript based renderers within 
 GorillaREPL? It would be nice to support interactive figures with this 
 kind of use case (in addition to SVG based plots, of course). 

 From the responses thus far, it appears that ggplot is the gold 
 standard for composable, customizable charts. Once we get the 
 dataframe format right, I'll invest some time into learning what I can 
 from it. We certainly want any implementation to be as data driven as 
 possible. 

 Thanks, 

 Lucas 


 On 13 December 2014 at 22:42, Jony Hudson jonye...@gmail.com 
 javascript: wrote: 
  I think it would be great, and a very useful contribution to the Clojure 
  world, to have a flexible plotting library. My perspective, at risk of 
 going 
  a bit off-topic, and from the biased position of a Gorilla REPL author 
 ... 
  
  
  When I think about the sort of programming I do as a scientist - data 
  analysis, modelling, numerics, statistics - I have a few requirements: 
  
  
  - For me, having a notebook interface is essential. It's how I think. 
 It's 
  the interactivity of the REPL, plus rich output, plus note-taking. 
  
  - I'd like to write my code in a civilised language. Ideally one that 
 puts 
  data first, because that's at the heart of the problems I solve. 
  
  - I want to be able to make things run fast when I need to. So I need 
 some 
  ability to write low-level code on occasion. 
  
  - I'd rather not re-write the whole world, so libraries are good. 
  
  - I want to be able to plot things the way I want them. 
  
  
  If I think about the possible contenders, written as (Notebook 
 interface, 
  language, low-level language escape hatch) then the ones I'm familiar 
 with, 
  and are advanced enough to use day-to-day for work, are: 
  
  
  (Gorilla REPL, Clojure, Java) 
  
  (IPython, Python, C) 
  
  (R, R, C) 
  
  (Mathematica notebook, Wolfram language, 
  sort-of-C/sort-of-Java/sort-of-.NET) 
  
  
  In terms of the interface, obviously Gorilla REPL is the best of the 
 bunch 
  :-) From a language perspective, my opinion is Clojure/Java wins this 
  hands-down. Preaching to the choir here, but Clojure is great for 
  data-oriented programming, and importantly for me, it's _really_ easy to 
  drop into Java when it matters. Library-wise, all are strong. Each has 
 their 
  own advantages, but I'd say the Clojure/Java ecosystem has enough that, 
 for 
  what I do, I rarely get stuck. For plotting Mathematica and R are 
 leagues 
  ahead. I'm not familiar with the latest developments in Python, but last 
 I 
  looked I didn’t see anything doing it the way I think it should be done. 
  
  
  Which, brings me to why I’m sharing all of this unsolicited opinion … 
 it’s 
  because I think a really strong plotting library would position Clojure 
  alongside the very best environments to do science and technical 
  computing/data science (or whatever it is we’re calling “thinking about 
 data 
  with a computer” these days). Gorilla/Clojure works great for me, but I 
 do 
  fire up R and Mathematica frequently for more advanced plotting. So, a 
  full-featured plot library is something I’d love to see happen, and 
 would 

Handling increasingly-intensive processes

[Sam Raker]

I'm (still) pulling tweets from twitter, processing them, and storing them 
in CouchDB with hashtags as doc ids, such that if a tweet contains 3 
hashtags, that tweet will be indexed under each of those 3 hashtags. My 
application hits CouchDB for the relevant document and uses Cheshire to 
convert the resulting string to a map. The map's values consist of a few 
string values and an array that consists of all the tweets that contain 
that hashtag. The problem is thus with common hashtags: the more tweets 
contain a given hashtag, the long that hashtag's tweets array will be, 
and, additionally, the more often that document will be retrieved from 
CouchDB. The likelihood and magnitude of performance hits on my app are 
therefore correlated, which is Bad.

I'm reaching out to you all for suggestions about how best to deal with 
this situation. Some way of caching something, somehow? I'm at a loss, but 
I want to believe there's a solution.


Thanks,
-sam

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Charting Data Format Feedback Requested

[Mikera]

It seems to me that we will need a multi-stage pipeline with a few 
different transformations available. This will give many benefits:
a) People can mix and match the components they need for the particular 
project
b) We avoid unnecessary dependencies for people who don't want / can't 
support them
c) We can avoid duplicated effort on shared stages
d) Each step itself can be simpler and more maintainable (the non-visual 
steps at least should be very testable pure functions etc.)

I can see a few steps that we might want to support.

(CLJ) analytical tools = core.matrix dataset (this could cover all kinds 
of analytics, queries, machine learning outputs etc.)
(CLJ) core.matrix dataset = common chart format (roughly as Lucas suggests 
above)
(CLJ) common chart format = Java based charting (e.g. JFreechart, as in 
Incanter)
(CLJ/CLJS) common chart format = Vega format (for Gorilla REPL etc.)
(CLJ/CLJS) Vega format = SVG (Gorilla renderer already does this, right?)
(CLJS) common chart format = Om-wrapped Javascript charting component (D3, 
NVD3 etc.)

I'm sure there are other important transformations that I have missed, but 
I hope I have conveyed the broad idea?

Interactivity is, I think, a separate problem. We should keep that separate 
from the pure data definitions and transformations. There are many 
different possible interaction patterns and we shouldn't be prescriptive 
about this. People will also undoubtedly come up with clever ways to 
optimise interactivity e.g. with Om-like detection of deltas, so again we 
should avoid baking in too many assumptions in order to allow room for 
innovation.


On Monday, 15 December 2014 05:20:57 UTC+8, Jony Hudson wrote:

 Hi Lucas,

  I think, regarding integration with Gorilla, the real decision to be made 
 is around interactivity. For non-interactive charts, it would be ideal to 
 separate out the code that generates the chart from the code that messes 
 with the DOM. Gorilla would then just use the charting code, and do its own 
 DOM manipulation. It would probably also be ideal if the charting code ran 
 server-side (CLJ) for Gorilla's purposes.

 It sounds, though, that this is probably not the goal for your library. If 
 you are aiming to build something that can handle interactive 
 visualisations, and handle changing data, then I guess there's going to be 
 much more interaction between the charting code and the DOM manipulation 
 code. I'm not sure how that would fit in with Gorilla - but as a general 
 design point (which would also ease Gorilla integration) there might be 
 some value in making the interface between charting and DOM 
 manipulation explicit, so that it is possible to plug in different 
 approaches to DOM manipulation. That's not to say that this is 
 realistically possible, just that I'd put it on the wishlist :-)

 My current plan with Gorilla was to steer clear of interactivity, for two 
 reasons: one, that for the sort of stuff I do myself, it's not really that 
 useful (or, as I've said before: the interactivity you already get at the 
 REPL is plenty); and two, because it looks like it's really, _really_ hard 
 to get right! That said ... I recognise that people do do things that would 
 be improved by interactivity, so if it is possible to make it work cleanly, 
 then it is something I'd be keen to support in Gorilla :-)


 Jony

 On Sunday, 14 December 2014 12:26:17 UTC, Lucas Bradstreet wrote:

 Hi Jony, 

 I'm a fan of Gorilla REPL. I'd love to have this work supported with 
 it. Is it easy to support Clojurescript based renderers within 
 GorillaREPL? It would be nice to support interactive figures with this 
 kind of use case (in addition to SVG based plots, of course). 

 From the responses thus far, it appears that ggplot is the gold 
 standard for composable, customizable charts. Once we get the 
 dataframe format right, I'll invest some time into learning what I can 
 from it. We certainly want any implementation to be as data driven as 
 possible. 

 Thanks, 

 Lucas 


 On 13 December 2014 at 22:42, Jony Hudson jonye...@gmail.com wrote: 
  I think it would be great, and a very useful contribution to the 
 Clojure 
  world, to have a flexible plotting library. My perspective, at risk of 
 going 
  a bit off-topic, and from the biased position of a Gorilla REPL author 
 ... 
  
  
  When I think about the sort of programming I do as a scientist - data 
  analysis, modelling, numerics, statistics - I have a few requirements: 
  
  
  - For me, having a notebook interface is essential. It's how I think. 
 It's 
  the interactivity of the REPL, plus rich output, plus note-taking. 
  
  - I'd like to write my code in a civilised language. Ideally one that 
 puts 
  data first, because that's at the heart of the problems I solve. 
  
  - I want to be able to make things run fast when I need to. So I need 
 some 
  ability to write low-level code on occasion. 
  
  - I'd rather not re-write the whole world, so libraries 

Re: Implementing a Oauth2 provider with clauth and friend

[Dave Della Costa]

You could also take a look at friend-oauth2 if you are using it in the
context of Friend--if it doesn't work for you for some reason I'd like
to know why, as I'd like it to be able to handle this use-case.

https://github.com/ddellacosta/friend-oauth2

Thanks!

DD

(2014/12/15 3:08), Sebastian Bensusan wrote:
 Hi,
 
 I am writing a Single Page Application using Om that communicates via
 XHR with a REST API using compojure + liberator. I should be able to
 authenticate users by using email  password credentials or third party
 Oauth2 like Linkedin's. I
 
 My plan is: use clauth [1] to roll my own oauth2, package it as a friend
 credential-fn/workflow, and then wrap the liberator api with
 friend [2]  and the third parties workflows.
 
 Anybody has any pointers on how to do this? It is a complex solution but
 I have no ideas on how to simplify it. 
 
 Thanks for your time!
 
 Sebastian
 
 [1] https://github.com/pelle/clauth
 [2] 
 http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/
 
 -- 
 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
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+unsubscr...@googlegroups.com
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling increasingly-intensive processes

[Ashton Kemerling]

Apologies on the email flood, my email client decided to do the most 
useless of all possible actions.


On Sun, Dec 14, 2014 at 11:53 PM, Ashton Kemerling 
ashtonkemerl...@gmail.com wrote:
Honestly, it sounds like you'll either need to move the indexing into 
memor


On Sun, Dec 14, 2014 at 8:54 PM, Sam Raker sam.ra...@gmail.com 
wrote:
I'm (still) pulling tweets from twitter, processing them, and 
storing them in CouchDB with hashtags as doc ids, such that if a 
tweet contains 3 hashtags, that tweet will be indexed under each of 
those 3 hashtags. My application hits CouchDB for the relevant 
document and uses Cheshire to convert the resulting string to a map. 
The map's values consist of a few string values and an array that 
consists of all the tweets that contain that hashtag. The problem is 
thus with common hashtags: the more tweets contain a given hashtag, 
the long that hashtag's tweets array will be, and, additionally, 
the more often that document will be retrieved from CouchDB. The 
likelihood and magnitude of performance hits on my app are therefore 
correlated, which is Bad.


I'm reaching out to you all for suggestions about how best to deal 
with this situation. Some way of caching something, somehow? I'm at 
a loss, but I want to believe there's a solution.



Thanks,
-sam
--
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
--- 
You received this message because you are subscribed to the Google 
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
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
--- 
You received this message because you are subscribed to the Google Groups Clojure group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling increasingly-intensive processes

[Ashton Kemerling]

Sam,

It sounds like you need to either find a caching strategy that works for 
your application's needs, or you'll need to adjust how your data is stored 
(model or data store). Without knowing more about your performance and 
business needs I can't really speculate with any confidence.

--
Ashton

On Sunday, December 14, 2014 8:54:04 PM UTC-7, Sam Raker wrote:

 I'm (still) pulling tweets from twitter, processing them, and storing them 
 in CouchDB with hashtags as doc ids, such that if a tweet contains 3 
 hashtags, that tweet will be indexed under each of those 3 hashtags. My 
 application hits CouchDB for the relevant document and uses Cheshire to 
 convert the resulting string to a map. The map's values consist of a few 
 string values and an array that consists of all the tweets that contain 
 that hashtag. The problem is thus with common hashtags: the more tweets 
 contain a given hashtag, the long that hashtag's tweets array will be, 
 and, additionally, the more often that document will be retrieved from 
 CouchDB. The likelihood and magnitude of performance hits on my app are 
 therefore correlated, which is Bad.

 I'm reaching out to you all for suggestions about how best to deal with 
 this situation. Some way of caching something, somehow? I'm at a loss, but 
 I want to believe there's a solution.


 Thanks,
 -sam


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mocking java class for test.

[Eunmin Kim]

Hi! My question is, How can I exchange a java class for test like 
`with-redefs`?

(defn run-a
  []
  (... some logic
 (.run (AClass. )))

(deftest some-test
  (with-redefs [AClass MockAClass] ;; ???
(is (run-a)))



-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.