Stefan Weiss wrote:
> On 23.03.2011 02:35, Scott Sauyet wrote:
>> npup wrote:
Welcome to the discussion, Stefan! Glad to have your keen mind
aboard.
> If the most common reaction to non-conformance is to throw an Error, and
> you want to avoid unnecessary if/else branching, you could introduce a
> convenience method to do both. Maybe something like
>
> // code code code...
> Conform.assert(spec, obj);
> // now we're safe. yay. more code code code...
> [ ... ]
That was my first thought as to the use of the API presented. If
that's the usual reaction, this works well.
Lately I've done an awful lot of code that looks like
if (param && isFunction(param.fn) && isBoolean(param.val)) {
result = param.fn(param.val);
return Math.max(result, isNumber(param.min) ? param.min : 0);
} else {
return defaultVal;
}
In such cases, non-conformance is a reasonable possibility, not an
error. I definitely would not want to throw an error myself and would
absolutely hate having to wrap a try-catch around my own code to deal
with this from a utility class.
I would love it if that code could be replaced with
return conforms(spec, param)) ? Math.max(param.fn(param.val),
param.min || 0) || defaultVal
> <aside>I used "Conform" as a temporary placeholder instead of Acts or
> Acts.As because I'm not convinced that those are very good names for a
> conformance checker. I mean, yeah, it's cute to write
> Acts.As(something), but that breaks down as soon as you want to use any
> other method or property of Acts.As - such as Acts.As.info. On a
> semantic level, I'm also wondering what the Acts object represents. It
> sounds vaguely biblical, but that's not really my forte ;)</aside>
Hey, it's less cutesy than Nick Fitzgerald's "quacksLike", which npup
references in the blog post referred to in the OP.
> More random thoughts:
> .) methods which accept an 'obj' parameter could optionally also accept
> an array of objects.
I'd be more interested in accepting multiple specifications than
multiple objects:
if (Conform(flying, waterDwelling).check(myMallard)) {
// ...
}
> .) another convenience wrapper for actsAs() might be violates() -
> similar to actsAs, but opposite results.
> .) there could be a check() method which would return an info object for
> those who want to know exactly what went wrong.
>
> There is also an alternative to currying. "Conform" (or whatever catchy
> name you can come up with) could be more than a simple namespace; it
> could be a real constructor:
>
> var addrCheck = new Conform(addressSpec);
> if (addrCheck.passes(obj)) {
> // we're fine
> } else {
> throw Error(addrCheck.lastError());
> }
>
> This way, you can have "static" methods like Conform.actsAs,
> Conform.check, Conform.assert, etc, and also specialized Conform objects
> with a stored specification object.
This might be nice, so long as the static methods allow the simple use
cases.
Conform.actsAs(spec, obj) : boolean
Conform.check(spec, obj): array of errors
Conform.assert(spec, obj): no return but throws error
var conform = new Conform(spec);
conform.actsAs(obj): boolean
conform.check(obj): array of errors
conform.assert(obj): no return but throws error
Again here, though, the second version of actsAs seems mis-named. The
first one is fine, but the second one doesn't feel right. Perhaps
"validate" would be the best bet.
> API design is fun. There are 1001 different ways to meet the same goal,
> and the more complex your requirements are, the less likely it is that
> two people will agree on which way is best. It's even more fun when
> you're in a position to lay down the law :)
Agreed. And who better to lay down the law than us? :-)
> IMHO, it's less fun when you paint yourself into a corner by using a
> name like "Acts.As", because then you're basically limiting yourself to
> answering a single question.
... although that can also be very satisfying.
I started my own implementation last night based upon simply reversing
the sense of npup's Act.As. I think it's already time for an API
redesign.
-- Scott
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
