Native Assertion module?
I recall something from ES4 days but can find only
A built-in assert special form recognized by the compiler could be passed a quoted string of its expression, along with source coordinates.
(I am sorry that I mistakenly sent this only to Rick Waldron. I intended it for es-discuss.)
On Mon, Feb 13, 2012 at 5:04 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
I was wondering if a native Assertion module had ever been discussed or proposed - I searched[1] and found nothing. If anyone can point me to existing discussion or proposals that I might have missed, I was be greatly appreciative. The simplest explanation of my thinking is something closer to a "standard lib" module, similar to Globalization or "Iter".
If you do a native Assertion module, maybe it should be similar to node's.
nodejs.org/docs/latest/api/assert.html
This being said, the node authors only added the "assert" api because they use it in node. I find no compelling reason to have that in JS.
Citation from Isaac Shlueter:
If you do a native Assertion module, maybe it should be similar to node's.
It's worth noting that Node's assert is almost (?) identical to CommonJS's Unit Testing spec 1. I'm not sure which came first.
Regardless, I think this is the job for a body like CommonJS (as problematic as it may be), not Ecma.
On Feb 13, 2012, at 2:21 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
If you do a native Assertion module, maybe it should be similar to node's.
It's worth noting that Node's assert is almost (?) identical to CommonJS's Unit Testing spec [1]. I'm not sure which came first.
Regardless, I think this is the job for a body like CommonJS (as problematic as it may be), not Ecma.
I speak for myself and my colleagues when I say that we've had our fill of including scripts just for the sake of having a common testing interface.
Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code.
On Mon, Feb 13, 2012 at 7:03 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Feb 13, 2012, at 2:21 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
If you do a native Assertion module, maybe it should be similar to node's.
It's worth noting that Node's assert is almost (?) identical to CommonJS's Unit Testing spec [1]. I'm not sure which came first.
IIRC node's assert was built off the CommonJS spec and hasn't really diverged much since.
Regardless, I think this is the job for a body like CommonJS (as problematic as it may be), not Ecma.
CommonJS is effectively defunct. As far as I know TC-39 is really the only group in the position to pave this cowpath (and this is an explicit goal of harmony, after all). This is certainly a well-trodden path and it only needs the tiny subset of node's assert to be useful.
The problem with API surfaced defined outside of TC-39 is there's no place
to put them. Your require("assert") could be a lot different than mine,
and this is a problem. A minimal API agreed to by the committee would go a
long way helping here, especially if (like Set and Map) it was given a
standard, official place in the global es environment.
On a related note: has anyone given any thought to what shims should do about emulating @std modules? Or is there a programmatic loader API that's easy enough to shim in? That would make this kind of cowpath-paving far more fruitful.
Another related note: isn't it about time the spec say something about console? :)
I speak for myself and my colleagues when I say that we've had our fill of including scripts just for the sake of having a common testing interface.
Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code.
Amen.
On 2/13/12 at 16:03, waldron.rick at gmail.com (Rick Waldron) wrote:
Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code.
IMHO, things started going to the dogs in the mid-1970s when IBM decided to "manage" bugs instead of fixing them. It't been downhill ever since. :-)
Cheers - Bill
Bill Frantz |"After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it?" -- Marcus Ranum
On Feb 13, 2012, at 4:03 PM, Rick Waldron wrote:
I speak for myself and my colleagues when I say that we've had our fill of including scripts just for the sake of having a common testing interface.
A reasonable point. OTOH, I wouldn't want to over-engineer. And the larger the API, the harder it will be to standardize. I'm thinking maybe just a couple bare-bones primitives:
- AssertionError <: Error
- assert(x === 12); // throws an AssertionError with a default error message
- assert(x === 12, "twelve, supposedly") // throws an AssertionError with the given error message
Thoughts?
On Feb 13, 2012, at 6:43 PM, Dean Landolt wrote:
On a related note: has anyone given any thought to what shims should do about emulating @std modules? Or is there a programmatic loader API that's easy enough to shim in? That would make this kind of cowpath-paving far more fruitful.
There's definitely a programmatic loader API, but we're hacking on the wiki these days. More to come this week.
Another related note: isn't it about time the spec say something about console? :)
Could be, although we can't really mandate how console.log produces output. But we could at least say "here's the API, and it can produce output in some host-environment-specific way."
There's both room and need for a built-in assert() IMHO -- I would like one which magically compiles to nothing in production code.
On Tue, Feb 14, 2012 at 1:51 AM, David Herman <dherman at mozilla.com> wrote:
On Feb 13, 2012, at 4:03 PM, Rick Waldron wrote:
I speak for myself and my colleagues when I say that we've had our fill of including scripts just for the sake of having a common testing interface.
A reasonable point. OTOH, I wouldn't want to over-engineer. And the larger the API, the harder it will be to standardize. I'm thinking maybe just a couple bare-bones primitives:
- AssertionError <: Error
- assert(x === 12); // throws an AssertionError with a default error message
- assert(x === 12, "twelve, supposedly") // throws an AssertionError with the given error message
Bingo :)
On Tue, Feb 14, 2012 at 10:45 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:51 AM, David Herman <dherman at mozilla.com> wrote:
On Feb 13, 2012, at 4:03 PM, Rick Waldron wrote:
I speak for myself and my colleagues when I say that we've had our fill of including scripts just for the sake of having a common testing interface.
A reasonable point. OTOH, I wouldn't want to over-engineer. And the larger the API, the harder it will be to standardize. I'm thinking maybe just a couple bare-bones primitives:
- AssertionError <: Error
- assert(x === 12); // throws an AssertionError with a default error message
- assert(x === 12, "twelve, supposedly") // throws an AssertionError with the given error message
Bingo :)
Is this significantly better than console.assert()?
jjb
On Tue, Feb 14, 2012 at 1:50 PM, John J Barton <johnjbarton at johnjbarton.com>wrote:
On Tue, Feb 14, 2012 at 10:45 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:51 AM, David Herman <dherman at mozilla.com> wrote:
On Feb 13, 2012, at 4:03 PM, Rick Waldron wrote:
I speak for myself and my colleagues when I say that we've had our fill
of including scripts just for the sake of having a common testing interface.
A reasonable point. OTOH, I wouldn't want to over-engineer. And the larger
the API, the harder it will be to standardize. I'm thinking maybe just a couple bare-bones primitives:
- AssertionError <: Error
- assert(x === 12); // throws an AssertionError with a default error message
- assert(x === 12, "twelve, supposedly") // throws an AssertionError with
the given error message
Bingo :)
+1
I assume nothing stops us from subtyping AssertionError either, right?
Is this significantly better than console.assert()?
Dave's assert throws an AssertionError (a new global, presumably?). But more importantly, it actually throws, which is an important departure from console.assert.
I was wondering if a native Assertion module had ever been discussed or proposed - I searched[1] and found nothing. If anyone can point me to existing discussion or proposals that I might have missed, I was be greatly appreciative. The simplest explanation of my thinking is something closer to a "standard lib" module, similar to Globalization or "Iter".
[1] doku.php?do=search&id=assert