coincidentally, me and my brother wrote this while on the train to
rubyconf last year:
https://github.com/mikejones/mississippi
havent put any docs or anything on there (its only a couple of
functions), but is essentially a validation function that take a map
(the thing to validate) and another m
On 12 April 2011 22:04, Joost wrote:
> For now, I think of the pretzel library as the lowest useful level of
> abstraction for input tests. And for low level abstractions, I prefer
> to place a higher value on correctness, extensibility, consistency and
> possibly even performance (in roughly that
I noticed I hadn't addressed this question earlier, so.
On Apr 9, 3:48 am, James Reeves wrote:
> The problem I have with such a scheme is that it seems more complex to
> use in practise. For instance, let's say I wanted an optional value.
> If predicates that fail a precondition return a truthy
On Apr 12, 6:35 pm, James Reeves wrote:
> On 12 April 2011 12:16, Joost wrote:
>
> > An input string of "foobar" is obviously not a number between 10 and
> > 20, so whatever predicate you use to test for that should just return
> > false. That not everybody here agrees on that indicates to me tha
On 12 April 2011 12:16, Joost wrote:
> An input string of "foobar" is obviously not a number between 10 and
> 20, so whatever predicate you use to test for that should just return
> false. That not everybody here agrees on that indicates to me that
> people are trying to shove too much functionali
On Tue, Apr 12, 2011 at 8:05 AM, James Reeves wrote:
> On 12 April 2011 12:02, Ken Wesson wrote:
>> Don't be ridiculous. If you're putting that (chain ...) sexp of yours
>> in every separate place where a field is checked for being an integer
>> in a range, then that's duplication. And if you ext
On 12 April 2011 12:02, Ken Wesson wrote:
> Don't be ridiculous. If you're putting that (chain ...) sexp of yours
> in every separate place where a field is checked for being an integer
> in a range, then that's duplication. And if you extract it into a
> function that just takes the endpoints as
All this stuff on complexity of validations is interesting, but my
take on most of this (and especially on the pretzel functions) is that
predicates should just test for validity, strictly if possible, and
nothing else, since there are too many ways of combining these tests
into more abstract funct
On Tue, Apr 12, 2011 at 6:34 AM, James Reeves wrote:
> On 12 April 2011 04:31, Ken Wesson wrote:
>> There's a difference between the program parsing the same *object*
>> multiple times, and the program's own source code containing
>> duplication!
>
> But there isn't any duplication
Don't be ridi
On 12 April 2011 04:31, Ken Wesson wrote:
> There's a difference between the program parsing the same *object*
> multiple times, and the program's own source code containing
> duplication!
But there isn't any duplication:
(defn present? [x]
(not (string/blank? x)))
(defn- parse-int [x]
(try
On Mon, Apr 11, 2011 at 10:23 PM, James Reeves wrote:
> On 12 April 2011 01:41, Ken Wesson wrote:
>> On Mon, Apr 11, 2011 at 7:09 PM, James Reeves
>> wrote:
>>> You wouldn't necessarily need to explicitly verify each precondition,
>>> but it might be the case that the same string is parsed mult
On 12 April 2011 01:41, Ken Wesson wrote:
> On Mon, Apr 11, 2011 at 7:09 PM, James Reeves wrote:
>> You wouldn't necessarily need to explicitly verify each precondition,
>> but it might be the case that the same string is parsed multiple
>> times. However, I'm unsure why you think this is a probl
On Mon, Apr 11, 2011 at 7:09 PM, James Reeves wrote:
> On 11 April 2011 21:26, Ken Wesson wrote:
>> On Mon, Apr 11, 2011 at 1:09 PM, James Reeves
>> wrote:
>>> If you already have a, b, and c, then compounding them into one
>>> function, only to then use a map to split them up again doesn't see
On 11 April 2011 21:26, Ken Wesson wrote:
> On Mon, Apr 11, 2011 at 1:09 PM, James Reeves wrote:
>> If you already have a, b, and c, then compounding them into one
>> function, only to then use a map to split them up again doesn't seem a
>> good solution.
>
> The preconditions have to be checked.
On Mon, Apr 11, 2011 at 1:09 PM, James Reeves wrote:
> On 11 April 2011 09:43, Ken Wesson wrote:
>> On Mon, Apr 11, 2011 at 4:12 AM, James Reeves
>> wrote:
>>> Yes, but remember that I said I was looking for non-compound
>>> solutions. In my view, simple functions are more idiomatic Clojure.
>>
On Mon, Apr 11, 2011 at 7:17 AM, Meikel Brandmeyer wrote:
>
>> I do. And I also admit, that I think that someone not able to write a
>> simple, non-critical application in a robust and fault tolerant way
>> per default is a able to write a complex, critical application in a
>> robust and fault tol
On 11 April 2011 09:43, Ken Wesson wrote:
> On Mon, Apr 11, 2011 at 4:12 AM, James Reeves wrote:
>> Yes, but remember that I said I was looking for non-compound
>> solutions. In my view, simple functions are more idiomatic Clojure.
>
> Mine were built up starting from very simple functions.
Sure
> I do. And I also admit, that I think that someone not able to write a
> simple, non-critical application in a robust and fault tolerant way
> per default is a able to write a complex, critical application in a
> robust and fault tolerant way.
Bleh. ... that I *don't* think ...
--
You received
Hi,
On 11 Apr., 12:45, Ken Wesson wrote:
> But you must admit that the mission-criticalness of robustness and
> fault tolerance varies from one application to the next.
I do. And I also admit, that I think that someone not able to write a
simple, non-critical application in a robust and fault t
On Mon, Apr 11, 2011 at 6:27 AM, Meikel Brandmeyer wrote:
> Although not every system launches the Rockets, I'd prefer systems
> with robustness and fault tolerance as default. Even if it's only the
> egg clock gadget.
But you must admit that the mission-criticalness of robustness and
fault toler
On Mon, Apr 11, 2011 at 5:29 AM, Meikel Brandmeyer wrote:
> Hi,
>
> On 11 Apr., 11:16, Ken Wesson wrote:
>
>>> Just for illustration: Who designs a system, which starts an atomic
>>> war on a bitflip in a test message? (Yeah, this happened and we are
>>> only alive because of the gut feeling of a
Hi,
On 11 Apr., 12:04, Ken Wesson wrote:
> So, similar incidents happened on both sides.
And to illustrate this point:
>> Because the phantasy of the average human being is quite limited.
>
> ?
No one obviously imagined what happens when there is a malfunction in
the hardware which might caus
On Mon, Apr 11, 2011 at 5:07 AM, Meikel Brandmeyer wrote:
>> What is your basis for this?
>
> Because the phantasy of the average human being is quite limited.
?
> While a missed "this is allowed" might cause trouble, it doesn't
> compromise the system. A missed "this is not allowed" however wil
Hi,
On 11 Apr., 11:16, Ken Wesson wrote:
>> Just for illustration: Who designs a system, which starts an atomic
>> war on a bitflip in a test message? (Yeah, this happened and we are
>> only alive because of the gut feeling of an operator.
>
> Petrov?
This was on the russian side. But it also h
Hi,
On 11 Apr., 10:43, Ken Wesson wrote:
> What is your basis for this?
Because the phantasy of the average human being is quite limited.
While a missed "this is allowed" might cause trouble, it doesn't
compromise the system. A missed "this is not allowed" however will.
Solutions are not always
On Mon, Apr 11, 2011 at 4:12 AM, James Reeves wrote:
> On 11 April 2011 08:31, Ken Wesson wrote:
>>> So your not-int-in-range? function is a compound function, made up of
>>> four simple functions.
>>
>> So? This whole discussion arose because some of them have
>> preconditions, like at-least 1 n
On 11 April 2011 08:31, Ken Wesson wrote:
>> So your not-int-in-range? function is a compound function, made up of
>> four simple functions.
>
> So? This whole discussion arose because some of them have
> preconditions, like at-least 1 not making sense for blank or
> non-integer input.
Yes, but r
On Mon, Apr 11, 2011 at 3:09 AM, James Reeves wrote:
> On 10 April 2011 22:24, Ken Wesson wrote:
>> On Sun, Apr 10, 2011 at 1:37 PM, James Reeves
>> wrote:
>>> By adding error messages to predicates, we tightly couple the
>>> validation error with the predicate, which in general is considered
>
On 10 April 2011 22:24, Ken Wesson wrote:
> On Sun, Apr 10, 2011 at 1:37 PM, James Reeves wrote:
>> By adding error messages to predicates, we tightly couple the
>> validation error with the predicate, which in general is considered
>> bad. However, this might be a valid compromise, but only if i
On Sun, Apr 10, 2011 at 1:37 PM, James Reeves wrote:
> By adding error messages to predicates, we tightly couple the
> validation error with the predicate, which in general is considered
> bad. However, this might be a valid compromise, but only if it
> improves readability.
I showed two posts ag
On 10 April 2011 12:33, Ken Wesson wrote:
> I thought you were the one who wanted the strings moved out to a data
> structure that could be swapped with localized versions? :)
Not really. I just want the error messages to be independent of the predicates.
In essence, I'm looking for a solution w
On Sun, Apr 10, 2011 at 11:42 AM, James Reeves wrote:
> On 10 April 2011 09:49, Ken Wesson wrote:
>> (def age-invalid-en
>> {:low "age must be at least 1"
>> :high "nobody is THAT old!"
>> :blank "age is required"
>> :non-integer "age must be a whole number"})
>>
>> (def qty-invalid-en
>>
On 10 April 2011 09:49, Ken Wesson wrote:
> (def age-invalid-en
> {:low "age must be at least 1"
> :high "nobody is THAT old!"
> :blank "age is required"
> :non-integer "age must be a whole number"})
>
> (def qty-invalid-en
> {:low "quantity must be at least 1"
> :high "maximum 10 per cu
On Sat, Apr 9, 2011 at 10:12 PM, James Reeves wrote:
> On 9 April 2011 10:07, Ken Wesson wrote:
>>> That particular example ties a predicate to a particular error
>>> message. Error messages should be independent of predicates, otherwise
>>> they can't be localized or changed to fit a specific si
On 9 April 2011 10:07, Ken Wesson wrote:
>> That particular example ties a predicate to a particular error
>> message. Error messages should be independent of predicates, otherwise
>> they can't be localized or changed to fit a specific situation.
>
> It can always be an integer or a keyword (or a
On Sat, Apr 9, 2011 at 9:56 AM, James Reeves wrote:
> On 8 April 2011 23:21, Ken Wesson wrote:
>> Better yet: maybe we're looking at this backwards. Maybe what we want
>> isn't a predicate for *passed* validation, but a predicate for
>> *failed* validation:
>>
>> (defn s-blank? [x]
>> (if (empty
On 8 April 2011 23:21, Ken Wesson wrote:
> Better yet: maybe we're looking at this backwards. Maybe what we want
> isn't a predicate for *passed* validation, but a predicate for
> *failed* validation:
>
> (defn s-blank? [x]
> (if (empty? (.trim x)) "must not be blank"))
That particular example t
On Fri, Apr 8, 2011 at 9:48 PM, James Reeves wrote:
> I'm saying that if a predicate is passed a value that doesn't match a
> precondition, the predicate could return a truthy value, rather than
> false.
Better yet: maybe we're looking at this backwards. Maybe what we want
isn't a predicate for *
On 8 April 2011 08:43, Joost wrote:
>> What about predicates that operate on numbers encoded as strings? e.g.
>> "1" or "4.2".
>
> IMO, they should be in the strings package.
The strings namespace could get rather large then, considering that
strings are how most raw data is represented.
> Sure,
James Reeves wrote:
> On 7 April 2011 20:03, Joost wrote:
> > Yup. I'm mostly in the same boat. That's why all the predicates I've
> > produced for now are in the pretzel.strings namespace. I expect to end
> > up with few non-string predicates, but those will have to go into
> > pretzel.numbers or
On 7 April 2011 20:03, Joost wrote:
> Yup. I'm mostly in the same boat. That's why all the predicates I've
> produced for now are in the pretzel.strings namespace. I expect to end
> up with few non-string predicates, but those will have to go into
> pretzel.numbers or whatever make sense.
What ab
James Reeves wrote:
> On 7 April 2011 06:48, Joost wrote:
> > I think your choice of currying makes more sense, at least in the
> > context of validations, so it might be a good idea to switch pretzel
> > over to that scheme.
>
> Would it make sense for clj-decline?
Yes. The main idea of clj-decl
On 7 April 2011 06:48, Joost wrote:
> I think your choice of currying makes more sense, at least in the
> context of validations, so it might be a good idea to switch pretzel
> over to that scheme.
Would it make sense for clj-decline?
The Valip predicates are designed with HTML form validation i
On Apr 7, 1:47 am, James Reeves wrote:
> I've been writing a small validation library, Valip, with a number of
> included predicates. The predicates in Valip are curried if they have
> more than one argument, but there is probably some overlap between
> Valip and Pretzel, and it might be an idea
On 6 April 2011 13:27, Joost wrote:
> The idea is to have a simple collection of these kinds of functions
> outside of possibly unwanted frameworks. I'm using them myself for
> doing validation with clj-decline, but it should at least be useful
> for most code that has to deal with free-form text
Hi,
I've collected a bunch of predicate functions and bundled them up as
pretzel: https://github.com/joodie/pretzel
My main focus right now is towards string formatting predicates; tests
for decimals, hex, email, urls, etc. Plus I've added some functions
that combine predicates into new ones.
Th
46 matches
Mail list logo
