On Thu, May 26, 2016 at 5:41 PM, Erik Assum wrote:
> Not being good at reading other peoples mind, I’ll give my guess as to what
> Timothy was trying to suggest:
>
> If you define your input as a map with keys such as:
>
> {:type :switched ; can be :switched :dual or :something
> :pos 54}
>
> Yo
On Thursday, May 26, 2016 at 10:50:24 AM UTC-4, John Szakmeister wrote:
>
> I'm very much a fan of bailing out early in imperative
> programming as it helps to avoid a bunch of nested if conditions
> that are to follow and read. This typically comes up when
> checking arguments to ensure that
On Thu, May 26, 2016 at 7:09 PM, Mark Engelberg
wrote:
> On Thu, May 26, 2016 at 1:29 PM, John Szakmeister
> wrote:
>>
>>
>> Yeah, cond is definitely useful here, but not in general.
>>
>
> cond is useful in general, just not the cond that is built-in to Clojure.
Sorry, I didn't mean it that way
On Thu, May 26, 2016 at 1:29 PM, John Szakmeister
wrote:
>
> Yeah, cond is definitely useful here, but not in general.
>
>
cond *is* useful in general, just not the cond that is built-in to Clojure.
About 5 years ago, Christophe Grand pointed out in a blog post that cond,
augmented with a few ex
Not being good at reading other peoples mind, I’ll give my guess as to what
Timothy was trying to suggest:
If you define your input as a map with keys such as:
{:type :switched ; can be :switched :dual or :something
:pos 54}
You can make something like:
(defmulti verify-pos-for :type)
(def
(sorry for the repeat Nathan, this was meant to go to the list too)
On Thu, May 26, 2016 at 1:43 PM, Nathan Davis
wrote:
> First off, I should say that you should first consider alternative
> approaches before considering the options below. For example, cond seems
> well-suited for this particul
On Thu, May 26, 2016 at 2:12 PM, Timothy Baldridge wrote:
> I would suggest reviewing your data model a bit. One of the problems you
> are experiencing is that you are overloading the inputs to your function.
> And since they are overloaded you have to create a state machine of sorts to
> parse o
On Thu, May 26, 2016 at 1:47 PM, Sean Corfield wrote:
[snip]
> A pattern that I’ve also started using is something like this:
>
> (defn guarded-process [data]
> (some-> data
> first-guard
> second-guard
> (another-guard :with “parameters”)
> (process-the-d
I use a little short circuited threading macro to deal with this. Here's a
gist with the macro named short-> and how I would write out your first 2
validation steps.
https://gist.github.com/mikeball/10cc64fe97c119671918fb2d1d8b4118
The new spec stuff looks really interesting, haven't had a ch
I would suggest reviewing your data model a bit. One of the problems you
are experiencing is that you are overloading the inputs to your function.
And since they are overloaded you have to create a state machine of sorts
to parse out if the data is valid. Another approach is to use namespaced
keys
On 5/26/16, 7:50 AM, "John Szakmeister" wrote:
>def verify_position(pos, type):
># It's acceptable to have a None value--it just means don't
># change the position for the axis.
>if pos is None:
>return True
>
># Anything outside our limits is invalid.
>if (pos > 90) or
First off, I should say that you should first consider alternative
approaches before considering the options below. For example, cond seems
well-suited for this particular case:
(defn verify-position[pos type]
(cond (nil? pos) true
(or (> pos 90)
(< pos 0)) false
Ah, yea, having a 'data spec' specifically for validation is above and
beyond what I meant, which was having your domain contained within a single
data structure that can be validated using a number of possible techniques.
That validation would be separate from the code that's pulling it apart
down
On Thu, May 26, 2016 at 10:55 AM, Gary Trakhman wrote:
> I think the idiomatic way to handle this in clojure is to do all your
> validation upfront on a single descriptive data structure, perhaps in a
> single function, then bail early. That has the added advantage of being
> able to report multi
I'm very much a fan of bailing out early in imperative
programming as it helps to avoid a bunch of nested if conditions
that are to follow and read. This typically comes up when
checking arguments to ensure that they're valid (in range, of
acceptable values, etc). One of the major stumbling block
I think the idiomatic way to handle this in clojure is to do all your
validation upfront on a single descriptive data structure, perhaps in a
single function, then bail early. That has the added advantage of being
able to report multiple errors, instead of just the first, and is well
supported by
16 matches
Mail list logo
