These will be supported in future versions; this is not something that I
want to rush, nor is it something I want to hold up the first GNU release;
it is likely to be a much lesser-used feature.
The parser methods are now split into their own functions. This has a number
of benefits: The most immediate is the commit that will follow. The second
benefit is that the function is no longer a closure---all context
information is passed into it, and so it can be optimized by the JavaScript
engine accordingly.
The concept of stacked traits already existed in previous commits, but until
now, mixins could not be stacked without some ugly errors. This also allows
mixins to be stacked atop of themselves, duplicating their effect. This
would naturally have limited use, but it's there.
This differs slightly from Scala. For example, consider this ease.js mixin:
C.use( T ).use( T )()
This is perfectly valid---it has the effect of stacking T twice. In reality,
ease.js is doing this:
- C' = C.use( T );
- new C'.use( T );
That is, it each call to `use' creates another class with T mixed in.
Scala, on the other hand, complains in this situation:
new C with T with T
will produce an error stating that "trait T is inherited twice". You can
work around this, however, by doing this:
class Ca extends T
new Ca with T
In fact, this is precisely what ease.js is doing, as mentioned above; the
"use.use" syntax is merely shorthand for this:
new C.use( T ).extend( {} ).use( T )
Just keep that in mind.
More information on this implementation and the rationale behind it will
appear in the manual. See future commits.
(Note the TODOs; return values aren't quite right here, but that will be
handled in the next commit.)
This is a consequence of ease.js' careful trait implementation that ensures
that any mixed in trait retains its API in the same manner that interfaces
and supertypes do.
There does not seem to be tests for any of the metadata at present; they are
implicitly tested through various implementations that make use of them.
This will also be the case here ("will"---in coming commits), but needs to
change.
The upcoming reflection implementation would be an excellent time to do so.
This will allow for additional processing before actually triggering the
warnings. For the sake of this commit, though, we just keep with existing
functionality.
This adds the `weak' keyword and permits abstract method definitions to
appear in the same definition object as the concrete implementation. This
should never be used with hand-written code---it is intended for code
generators (e.g. traits) that do not know if a concrete implementation will
be provided, and would waste cycles duplicating the property parsing that
ease.js will already be doing. It also allows for more concise code
generator code.
Note that, even though it's permitted, the validator still needs to be
modified to permit useful cases. In particular, I need weak abstract and
strong concrete methods for use in traits.
This just saves some time and memory in the event that the trait is never
actually used, which may be the case in libraries or dynamically loaded
modules.
As described in <https://savannah.gnu.org/task/index.php#comment3>.
The benefit of this approach over definition object merging is primarily
simplicitly---we're re-using much of the existing system. We may provide
more tight integration eventually for performance reasons (this is a
proof-of-concept), but this is an interesting start.
This also allows us to study and reason about traits by building off of
existing knowledge of composition; the documentation will make mention of
this to explain design considerations and issues of tight coupling
introduced by mixing in of traits.
Note the incomplete tests. These are very important, but the current state
at least demonstrates conceptually how this will work (and is even useful in
its current state, albeit dangerous and far from ready for production).
This is a rough concept showing how traits will be used at definition time
by classes (note that this does not yet address how they will be ``mixed
in'' at the time of instantiation).
More generally, this was a problem with not recursing on *all* of the
visibility objects of the supertype's supertype; the public visibility
object was implicitly recursed upon through JavaScript's natural prototype
chain, so this only manifested itself with protected members.
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 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.)
The concept of proxy methods will become an important, core concept in ease.js
that will provide strong benefits for creating decorators and proxies, removing
boilerplate code and providing useful metadata to the system. Consider the
following example:
Class( 'Foo',
{
// ...
'public performOperation': function( bar )
{
this._doSomethingWith( bar );
return this;
},
} );
Class( 'FooDecorator',
{
'private _foo': null,
// ...
'public performOperation': function( bar )
{
return this._foo.performOperation( bar );
},
} );
In the above example, `FooDecorator` is a decorator for `Foo`. Assume that the
`getValueOf()` method is undecorated and simply needs to be proxied to its
component --- an instance of `Foo`. (It is not uncommon that a decorator, proxy,
or related class will alter certain functionality while leaving much of it
unchanged.) In order to do so, we can use this generic, boilerplate code
return this.obj.func.apply( this.obj, arguments );
which would need to be repeated again and again for *each method that needs to
be proxied*. We also have another problem --- `Foo.getValueOf()` returns
*itself*, which `FooDecorator` *also* returns. This breaks encapsulation, so we
instead need to return ourself:
'public performOperation': function( bar )
{
this._foo.performOperation( bar );
return this;
},
Our boilerplate code then becomes:
var ret = this.obj.func.apply( this.obj, arguments );
return ( ret === this.obj )
? this
: ret;
Alternatively, we could use the `proxy' keyword:
Class( 'FooDecorator2',
{
'private _foo': null,
// ...
'public proxy performOperation': '_foo',
} );
`FooDecorator2.getValueOf()` and `FooDecorator.getValueOf()` both perform the
exact same task --- proxy the entire call to another object and return its
result, unless the result is the component, in which case the decorator itself
is returned.
Proxies, as of this commit, accomplish the following:
- All arguments are forwarded to the destination
- The return value is forwarded to the caller
- If the destination returns a reference to itself, it will be replaced with
a reference to the caller's context (`this`).
- If the call is expected to fail, either because the destination is not an
object or because the requested method is not a function, a useful error
will be immediately thrown (rather than the potentially cryptic one that
would otherwise result, requiring analysis of the stack trace).
N.B. As of this commit, static proxies do not yet function properly.
- Perhaps in future versions. The implementation details will not be ironed out before v0.1.0 and we can easily add it in the future without breaking BC. Getters/setters have not had too much attention thusfar in ease.js due to testing with systems that must work across many environments, including pre-ES5.
- This is a bug fix. The resulting class was not declared abstract, which is a problem if the resulting class chose not to provide a concrete implementation for each of the abstract members.
Getting ready for release means that we need to rest assured that everything is
operating as it should. Tests do an excellent job at aiding in this, but they
cannot cover everything. For example, a simple missing comma in a variable
declaration list could have terrible, global consequences.
Ah - you have to love those "ah-ha!" moments. The issue here is that both
uglify-js and closure compiler mangled the names in such a way that the var and
the function name had different values. In the case of closure compiler, the
function name was used to instantiate the constructor if the 'new' keyword was
omitted. This worked fine in all other tested browsers, but IE handles it
differently.
This little experience was rather frustrating. Indeed, it would imply that
the static implementation (at least, accessing protected and private static
members) was always broken in FF. I should be a bit more diligent in my testing.
Or perhaps it broke in a more recent version of FF, which is more likely. The
problem seems to be that we used defineSecureProp() for an assignment to the
actual class, then later properly assigned it to class.___$$svis$$.
Of course, defineSecureProp() makes it read-only, so this failed, causing
an improper assignment for __self, breaking the implementation. As such,
this probably broke in newer versions of FF and worked properly in older versions.
More concerningly is that the implementations clearly differ between Chromium
and Firefox. It may be that Firefox checks the prototype chain, whereas Chromium
(v8, specifically) will simply write to that object, ignoring that the property
further down the prototype chain is read-only.
Mike Gerwitz