Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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,

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: style question on tightly coupled functions

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

Re: Style-question: self-named attribute getters?

This answer says everything I would want to say better than I would say it. Second! Alex On Wednesday, June 25, 2014 9:12:01 PM UTC-5, Ryan Schmitt wrote: > > In object-oriented programming, encapsulation is always and everywhere > regarded as a highly significant design virtue, but the Clojure

Re: Style-question: self-named attribute getters?

Most Clojure libraries I've seen only give you a handful of namespaces. I would expect a moderately large Clojure library to expose, say, half a dozen at most. Remember that Clojure has no concept of star imports, even for Java classes, and imports will generally be qualified somehow (e.g. cloj

Re: Style-question: self-named attribute getters?

Thanks Ryan and James - that gives me a few more ideas on how to think about things. Hopefully some of the links Ryan posted will clarify things for me also. Ryan - yes my question about namespaces was to do with understanding the ideal granularity of namespaces. And more specifically, whethe

Re: Style-question: self-named attribute getters?

It sounds like you're building an API to provide documentation, but instead why not just document the data structure directly? Once you have your data structure design, add functions for non-trivial tasks. So something like "red?" seems a little too trivial and specific. The raw s-expression, (= (

Re: Style-question: self-named attribute getters?

The question of how to specify the "shape" of your data is an important one, and I think one of the contributions of Clojure is the way it isolates that problem, instead of complecting it with object-oriented design or static type checking. You might look at Prismatic Schema, a library that off

Re: Style-question: self-named attribute getters?

Thanks Ryan, Mike and James for your comments and info. Ryan I will follow up the links you posted. In the meantime, a request for some clarification... I have read / watched clojure stuff along these lines... ie that data hiding (in an immutable data context) is bad. I thought my approach wa

Re: Style-question: self-named attribute getters?

OOP places a strong emphasis on information hiding, particularly by wrapping data structures in APIs. Developers with a strong background in OOP tend to try to replicate this style of programming in Clojure. However, idiomatic Clojure emphasises exactly the opposite of this. In Clojure, a bare dat

Re: Style-question: self-named attribute getters?

In object-oriented programming, encapsulation is always and everywhere regarded as a highly significant design virtue, but the Clojure people have a bit of a different assessment, particularly when it comes to information. In one talk, Rich Hickey pointed out that encapsulation is for hiding im

Re: Style question (predicates)

My personal preference is that fns ending in ? return a strict boolean, to be consistent with clojure.core. If I need the value I create another fn. So I would have nsf-code? *and* get-nsf-code. Plus for more complicated values, if you change their representation you don't have to change the

Re: Style question (predicates)

This is a bit tangential, but your function "is-nsf-code?" brings up another style question. Is it really necessary to use the "is-" prefix? I used to do this too, but I realized recently that it is a Java-ism and seems out of place in Clojure. Clojure's boolean functions do fine without it bec

Re: Style question (predicates)

While *every?* and *not-any?* return true or false, *some* returns the first truthy value in a sequence, or nil if there are none. Similarly, *empty?* returns true or false, while *empty* and *not-empty*return a collection or nil. However, it seems as if* some*, *empty*, and *not-empty *are int

Re: Style question (predicates)

In the Common Lisp world it's common for predicates to return a useful value instead of T, when applicable. It seems possible the same principle could apply to clojure. >From CLtL2 : Often a predicate will return nil if it ``fails'' and

Re: Style question (predicates)

My 2p - I interpret the contract as being boolean. Truthy values are 'polymorphically' equivalent*1 so sure. The concern would be people relying on the implementation and treating the values as none-truthy (i.e. in your example relying on the fact it is a string being returned, so (= "someStr

Re: Style Question

I think I see the goal now: to allow calling with either a map or sequential key-value pairs. What you have appears correct and minimal for that purpose. For a function taking a sequence, you can accomplish something similar without a second arity by choosing to call directly or call using appl

Re: Style Question

The answer depends on what you're trying to accomplish. Does this simpler definition allow you to call blah in the ways you want to? (defn blah [& {:as blah-map}] ;; do stuff with blah-map) --Steve On Oct 10, 2010, at 12:39 AM, Grayswx wrote: > Recently, I've been coding functions that ta

Re: Style question

Hi, Am 16.10.2008 um 23:36 schrieb Tom Emerson: I'd like to solicit comments on better ways I could have written it: (defn- split-line [line] (let [parts (seq (.split line ":"))] (loop [mills (drop 1 parts) result (list (first parts))] (if (nil? mills) (reverse result)

Re: Style question

Meikel, Many thanks: I *knew* there had to be a more succinct way to do it... think I need to stare at the Clojure API documentation a bit more. :) Kind regards, -tree On Thu, Oct 16, 2008 at 5:48 PM, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote: > Hi, > > Am 16.10.2008 um 23:36 schrieb Tom

Re: Style question

On Oct 16, 5:36 pm, "Tom Emerson" <[EMAIL PROTECTED]> wrote: > Hello all, > > I wrote a function that behaves as: > > user> (split-line "785:3:39334:1:43103") > ("785" ("3" "39334") ("1" "43103")) > > I'd like to solicit comments on better ways I could have written it: > > (defn- split-line >