npup wrote:
> Scott Sauyet wrote:
>
>> I was suggesting something different, namely that the inverted sense
>> might be nicer to use in coding. I still don't have a better name
>> than "mismatches", which is fairly ugly.
>
>> What I didn't like about npup's original is that this was handled with
>> two separate calls:
>
>> if (Acts.As(spec, obj) {
>> // proceed knowing that the object matches the spec
>> } else {
>> throw new Error(Acts.As.info());
>> }
>
>> This wouldn't allow, for instance, the following:
>
>> if (Acts.As(spec1, obj1) {
>> if (Acts.As(spec2, obj2) {
>> // proceed knowing that all objects matches their specs
>> } else {
>> throw new Error(Acts.As.info());
>> }
>> } else {
>> throw new Error(Acts.As.info()); // fails to report accurately
>> }
> I don't see the point of reversing the wording here? Why not simply
> do:
>
> if (!Acts.As(spec, obj)) {
> throw Error(Acts.As.info());}
You're right. I was confused. There are still of course techniques
that are more difficult with this style, but they are not as bad as
I'd thought.
Am I right that this style would be more difficult?:
var results1 = mismatch(spec1, obj1),
results2 = mismatch(spec2, obj2);
if (results1 || results2) {
throw new Error(results1 || results2);
}
// proceed knowing that the objects match the spec
Will this work?:
var results1 = Acts.As(spec1, obj1),
error1 = results1 ? null : Acts.As.info(),
results2 = Acts.As(spec2, obj2),
error2 = results2 ? null : Acts.as.info();
if (error1 || error2) {
throw new Error(error1 || error2);
}
// proceed knowing that the objects match the spec
> That said, I am one of those who prefer throwing immediately instead
> of if-else-ing too much and thereby having the real work being done in
> some unnecessarily indented part of the code :)
I tend to be the same way, at least in JS. But I wouldn't like this
sort of API to dictate my program structure.
> I've been thinking of more ways to get around the "shared" info
> message quirk, but haven't found any super elegant solution yet.
Nor have I. Reversing the sense, though, does make using it somewhat
more elegant from a coding perspective.
> Had
> it been C programming I imagine there would be no hesitation to just
> stuff it in some supplied container object and return the boolean. But
> of course we want to do better :)
Or of course we could also simply return an object containing both a
boolean status and, if the status is false, another object with
details about the mismatch:
var match = Acts.As(spec, obj);
if (!match.results) {
throw new Error(match.info);
}
// proceed knowing that the object matches the spec
But this adds unnecessary clutter to the calling code.
If we could make our object false-y, we'd get the best of all worlds.
But, we can't as demonstrated by
var obj1 = {valueOf: function() {return 5}}; console.log(7 +
obj1); // 12
var obj2 = {valueOf: function() {return false}}; console.log(!
obj2); // false
That second one just seems wrong. But if you look at sections 9.2 and
9.3 of the ES specs, this is the expected behavior
In any case, a very interesting discussion. Thank you,
-- 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]
