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