On Mon, Apr 11, 2011 at 1:09 PM, James Reeves <jree...@weavejester.com> wrote:
> On 11 April 2011 09:43, Ken Wesson <kwess...@gmail.com> wrote:
>> On Mon, Apr 11, 2011 at 4:12 AM, James Reeves <jree...@weavejester.com>
>> 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, but all functions are. My point is that you have an additional
> layer of complexity that's I don't think is necessary:
>
> (defn not-abc [x]
> (cond
> (not (a x)) :a
> (not (b x)) :b
> (not (c x)) :c))
>
> ((not-abc x) {:a "A failed", :b "B failed", :c "C failed"}
>
> 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. The preconditions for
integer-in-range checks are the integer check and the non-blank check,
in the original example. I don't really see any way of simplifying
that further, unless the logic of verifying the preconditions is moved
out to the caller (and, thus, duplicated for every caller).
> In my view it's better to separate out the logic used to compound the
> function instead. e.g.
>
> (defn validation [f m]
> (fn [x] (if-not (f x) m)))
>
> (defn chain [& vs]
> (fn [x] (some (fn [v] (v x)) vs)))
>
> (chain
> (validation a "A failed")
> (validation b "B failed")
> (validation c "C failed"))
>
> Here each function does precisely one thing (i.e. they are simple), so
> we achieve the same effect without compounding.
You have compounding, via your "chain" here. You've just broken out a
couple of more explicit steps.
>>>> Is there anything that indicates they're more secure?
>>>
>>> I'd argue that encouraging people to think of what to allow is better
>>> than encouraging people to think of what to deny.
>>
>> What is your basis for this?
>
> Because if you forget to validate a field that is allow by default,
> then you end up with invalid data in your database and a potential
> security risk.
If you forget to do *anything* in a security-critical system, that's a
potential security risk.
> If, on the other hand, you forget to validate a field that is deny by
> default, then you end up with a failed validation.
Depending on the application, even dead functionality can be a
security risk. Perhaps it causes a police fingerprint-database search
to not work or produce a false negative, for instance.
Ultimately, assessing security risks requires knowing the particulars
of the application and its intended uses.
>>> Sure, and I'm not saying there aren't clear advantages to having
>>> inverted validations.
>>
>> Then why are you arguing as if you think I'm wrong about something?
>
> I'm not saying you're wrong. I'm saying that there are better
> solutions to the problem.
In some cases, perhaps.
> However, I'm not certain I'm right, and that's why I'm debating this;
> because I think your arguments have worth, and they could
> potentially change my mind.
Okay then.
--
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
