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