Sean James, yes of course there are times that it is _needed_. Agreed.
I just would never opt for using tools like declare and letfn as the _go to
tool_. I think of cyclic dependencies as less simple, harder to grok etc.
When you need it, by all means have the power to do so, but when you don't
n
On 20 November 2014 19:33, Alex Baranosky
wrote:
> Imo, that makes the let version even better. The Clojure compiler doesn't
> to allow circular dependencies, so I would consider the letfn behavior as
> "surprising" and therefore unideal.
>
It does, via declare. This is often necessary in parser
On Nov 20, 2014, at 11:33 AM, Alex Baranosky
wrote:
> Imo, that makes the let version even better. The Clojure compiler doesn't to
> allow circular dependencies, so I would consider the letfn behavior as
> "surprising" and therefore unideal.
Mutual recursion is a useful technique in some situa
Imo, that makes the let version even better. The Clojure compiler doesn't
to allow circular dependencies, so I would consider the letfn behavior as
"surprising" and therefore unideal.
On Thu, Nov 20, 2014 at 2:21 PM, Dan Girellini wrote:
> Using letfn allows the local functions to reference each
Using letfn allows the local functions to reference each other arbitrarily.
In your example, f2 can call f1 but not vice versa.
On Thu, Nov 20, 2014 at 11:08 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:
> letfn has no value imo. It is an unwritten stylistic rule I have to never
> us
letfn has no value imo. It is an unwritten stylistic rule I have to never
use it. Why introduce a new macro syntax for something that could just as
easily be written as?:
(let [f1 (fn [] ...)
f2 (fn [] ...)]
(+ (f1) (f2)))
On Thu, Nov 20, 2014 at 12:41 PM, henry w wrote:
> I never he
I never heard of letfn before. that looks like a clear way to do what i
need.
just found this stackoverflow thread which is relevant:
http://stackoverflow.com/questions/23255798/clojure-style-defn-vs-letfn
On Thu, Nov 20, 2014 at 3:34 PM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:
>
I'd structure my app like this.
Say there's one "pages" ns with code for different webpages
pages/index is a pretty short function
pages/dashboard is a more elaborate function and has two subcomponents:
->analytics, and ->user-info
pages.analytics/->analytics
pages.user-info/->user-info
On Thu,
henry w writes:
> you have understood my arguments pretty much. again the thing that
> bothers me is that f and g are logically part of x only, but are
> visible from y and z (even if and and y are declared higher up, the
> same problem applies to their own related, private fns and x).
Then decl
ok thanks for those thoughts.
you have understood my arguments pretty much. again the thing that bothers
me is that f and g are logically part of x only, but are visible from y and
z (even if and and y are declared higher up, the same problem applies to
their own related, private fns and x).
I'm not sure I understand your tidiness argument. If x uses g and f, and g
and f are private, that's plenty related enough for me to put them in the
same namespace, preferably right before x.
If f and g are meant to be private, the only reason I would see to put them
in a separate namespace is if
I guess the question is - why do the extracted functions look ugly or lack
cohesion if they still accomplish part of the task previously done by `x`?
If they are very general - you can consider moving them somewhere else and
making them public, otherwise they should stay in the same namespace, j
imagine in a namespace you have functions x, y, and z which are public.
function x grows a bit big, so is broken out so that it calls 2 other
functions, f and g.
now, imagine with all the clean code and refactoring in the world, still f
and g have nothing to do with y and z - but are declared
13 matches
Mail list logo
