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.
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.
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