This includes cleaning up the test case to remove tests now covered by the
conformance test case, and altering the implementation slightly for
conformance.
These conformance test cases will be an excellent disciplinary tool,
ensuring that any implementation of Eventable conforms strictly to its
specification; this will provide developers guarantees that the
implementation will work as expected polymorphically.
Some of these features will be introduced into jsTonic through additional
traits: for example, the magic `error` event that produces exceptions if
unhooked can be implemented using stackable traits or Evented trait
overrides (the former is superior and more generalized/independent).
This is introspection, which can be provided elsewhere or by specific
implementations. Together with the documented requirement (in Eventable#on)
that listeners must be notified of automatic un-hooking, and that systems
handling listeners will always be aware of when listeners are
hooked/unhooked, this method should not be necessary.
Including this method in Eventable also introduces incompatibility with
Node.js' Event API, which is undesirable.
This annotation is my own---there is not currently a system, insofar as I
know, that uses it. I'll be further formalizing things like this as I go,
but the idea is that I wish to provide asymptotic computational complexity
for all algorithms. Usually, these will be in Big O notation, which is
used (for better or for worse) to denote the upper bound of asymptomatic
growth. I will provide as tight of estimates as I can. Where the estimates
between upper and lower bounds differ significantly, I will provide both;
where they converge strongly, I'll use Big Theta notation---denoted by a
`@Theta` annotation---except in the case of constant time, for which I will
simply stick with Big O.
As a conscious TODO: need to properly handle attaching the same event
listener multiple times (define its behavior), and maybe even provide an API
to configure that behavior in some way.
It will take some getting used to (and it's a little sad to see some of the
long-standing conventions of ECMAScript vanish before my eyes), but it's
great thus far.
The primary motivation behind this was the concise function syntax, but
other features like block-level scoping, templating, and variable object
keys are quite convenient. I'm sure I'll be using others in this project as
well.
This may raise the question: isn't it odd using something that provides
class support in a library that is intended to augment GNU ease.js, which is
itself a class framework? Well, no, not really: GNU ease.js provides many
more powerful features that ES6/7 do not, which will be showcased
extensively in this library. ease.js will still work well with native
EMCAScript and interop will be adjusted as needed, but ease.js will not
become irrelevant.
Mike Gerwitz