We want these files to be available in the tarball for those who do not have the
setup necessary to build (which is far more likely to be the care with
JavaScript developers).
On Sun, Dec 22, 2013 at 03:31:08AM -0500, Richard Stallman wrote:
> I hereby dub ease.js a GNU package, and you its maintainer.
>
> Please don't forget to mention prominently in the README file and
> other suitable documentation places that it is a GNU program.
Thanks again to Brandon Inverson for providing this patch. All changes are his
except for the comment in configure.ac and the version.js.tpl move/changes.
Copyright-paperwork-exempt: Yes
This greatly simplfies rebasing and other operations while working in a branch;
signing each and every commit that is not in master can be overkill (even if it
does give peace of mind).
On Sat, Dec 21, 2013 at 12:29:23PM +0000, Brandon Invergo wrote:
> - configure.ac: add "foreign" to the AM_INIT statement so you don't have
> to do it from the command line
>
> - configure.ac: add a test for midair -p, which is standard boilerplate
> stuff
>
> - configure.ac: let the user dictate the locations of the java, node and
> closure-compiler executables via the JAVA, NODE and CCJAR environment
> variables
>
> - Makefile.am: use the MKDIR_P and CCJAR environment variables insntead
> of hard-coded paths
>
> - doc/Makefile: rename to doc/Makefile.am
>
> - doc/Makefile.am: remove manual infodoc handling; Automake can automate
> this stuff
>
> - doc/Makefile.am: support installing the documentation (install-plain,
> install-pdf, install-html), which gets installed usually to
> ${prefix}/share/doc/easejs (i.e. /usr/share/doc/easejs)
>
> - doc/classes.texi: fix some @ref macros
>
> - doc/manual.texi: fix the @include location
This implements recommendations by Brandon Invergo for the GNU submission
process, some of which is required by the GNU Coding Standards; I thank him for
his help and swift responses during this time.
This project was originally LGPLv+-licensed to encourage its use in a community
that is largely copyleft-phobic. After further reflection, that was a mistake,
as adoption is not the important factor here---software freedom is.
When submitting ease.js to the GNU project, it was asked if I would be willing
to relicense it under the GPLv3+; I agreed happily, because there is no reason
why we should provide proprietary software any sort of edge. Indeed, proprietary
JavaScript is a huge problem since it is automatically downloaded on the user's
PC generally without them even knowing, and is a current focus for the FSF. As
such, to remain firm in our stance against proprietary JavaScript, relicensing
made the most sense for GNU.
This is likely to upset current users of ease.js. I am not sure of their
number---I have only seen download counts periodically on npmjs.org---but I know
there are at least a small number. These users are free to continue using the
previous LGPL'd releases, but with the understanding that there will be no
further maintenance (not even bug fixes). If possible, users should use the
GPL-licensed versions and release their software as free software.
Here comes GNU ease.js.
Before this change, __super was set to undefined. However, consider that we have two
method overrides---foo and bar---and the code for bar is:
this.foo();
this.__super();
foo() would set __super to undefined and so bar cannot invoke its super method
unless it stores a reference to __super before invoking foo(). This patch fixes
this issue.
Getters/setters did not get much attention during the initial development of
ease.js, simply because there was such a strong focus on pre-ES5
compatibility---ease.js was created for a project that strongly required it.
Given that, getters/setters were not used, since those are ES5 features. As
such, I find that two things have happened:
1. There was little incentive to provide a proper implementation; even though
I noticed the issues during the initial development, they were left
unresolved and were then forgotten about as the project lay dormant for a
while.
2. The project was dormant because it was working as intended (sure, there
are still things on the TODO-list feature-wise). Since getters/setters were
unused in the project for which ease.js was created, the bug was never
found and so never addressed.
That said, I now am using getters/setters in a project with ease.js and noticed
a very odd bug that could not be explained by that project's implementation.
Sure enough, it was an ease.js issue and this commit resolves it.
Now, there is more to be said about this commit. Mainly, it should be noted that
MemberBuilder.buildGetterSetter, when compared with its method counterpart
(buildMethod) is incomplete---it does not properly address overrides, the
abstract keyword, proxies or the possibility of method hiding. This is certainly
something that I will get to, but I want to get this fix out as soon as I can.
Since overriding ES5 getters/setters (rather than explicit methods) is more
likely to be a rarity, and since a partial fix is better than no fix, this will
likely be tagged immediately and a further fix will follow in the (hopefully
near) future.
(This is an interesting example of how glaring bugs manage to slip through the
cracks, even when the developer is initially aware of them.)
Mike Gerwitz