This not only resolves the error triggered by the use of `super`, but also
is more proper, since that is what ease.js is being developed for; I handle
all ES3 fallback considerations myself.
Note that the build will now produce warnings, but the lines producing them
will be removed shortly in favor of a new API.
Strict mode fails on `typeof` for undefined variables, which was used
outside of strict mode for exactly the purpose of checking for undefined
variables! This check will work in either case.
During its initial development, no environments (e.g. Node.js, Chromium,
Firefox) supported strict mode; this has since changed, and node has a
--use-strict option, which is used in the test runner to ensure conformance.
See the introduced test cases for great detail; there was a problem with the
implementation where only the public API of the abstract trait object was
being checked, meaning that protected virtual methods were not found when
peforming the call. This was not a problem on override, because that proxies
to the protected member object (PMO), which includes protected members.
This allows invoking any arbitrary method of a supertype. This is needed,
for example, if some method `foo` is overridden, but we wish to call the
parent `foo` in another method; this is not possible with __super:
var C = Class(
{
'virtual foo': function() { return 'super'; }
} );
var SubC = C.extend(
{
'override foo': function() { return 'sub'; },
superfoo: function() { return this.foo.super.call( this ); }
} );
SubC().superfoo(); // 'super'
Obviously, __super would not work here because any call to __super within
SubC#superfoo would try to invoke C@superfoo, which does not exist.
This fixes a bug that causesd virtual definitions with parameters on classes
that a trait is mixed into to fail, and prevented proper param length
validations in the reverse case.
See test case description for a less confusing description.
When extending a class that is a subtype of a prototype, it would clobber
___$$vis$$, yielding a useless class. See the test case for a detailed
description.
Now that ease.js is a GNU project, it has much broader reach than before.
Since its very existence is controversial, it would be wise (and polite) to
provide a means for others to integrate with libraries written using ease.js
without being forced to use ease.js themselves. Further, ease.js users
should be able to build off of the work of other libraries that do not use
ease.js.
This set of changes introduces a number of interoperability improvements,
documented in the new manual chapter ``Interoperability''. Since it is
documented in the manual, this commit message will not go into great detail;
I wish to only provide a summary.
Firstly, we now have the concept of interface compatibility; while ease.js
classes/etc must still conform to the existing interface requirements, the
rules are a bit more lax for other ECMAScript objects to permit
interoperability with type-checking ease.js code. For example:
var I = Interface( { foo: [ 'a' ] } ),
obj = { foo: function( a ) {} };
Class.isA( I, obj ); // true
This is also a powerful feature for implementing interfaces around existing
objects, as a preemptive interface check (rather than duck typing).
Prototypally extending ease.js classes is potentially problematic because
the constructor may perform argument validations (this is also an issue in
pure prototypal code). As a solution, all classes now have a static
`asPrototype` method, which defers constructor invocation, trusting that the
prototype constructor will do so itself.
Aside from a few bug fixes, there is also a more concise notation for
private members to allow prototypal developers to feel more at home when
using GNU ease.js: members prefixed with an underscore are now implicitly
private, which will satisfy the most common visibility use cases. I do
recognize that some (mostly in the Java community) use underscore *suffixes*
to denote private members, but I've noticed that this is relatively rare in
the JS community; I have therefore not included such a check, but will
consider it if many users request it.
There are many more ideas to come, but I hope that this will help to bridge
the gap between the prototypal and classical camps, allowing them to
cooperate with as little friction as possible.
This was a nasty bug that I discovered when working on a project at work
probably over a year ago. I had worked around it, but ease.js was largely
stalled at the time; with it revitalized by GNU, it's finally getting fixed.
See test case comments for more information.
This is something that I've been aware of for quite some time, but never got
around to fixing; ease.js had stalled until it was revitalized by becoming a
GNU project.
This allows separation of concerns and makes the type system extensible. If
the type does not implement the necessary API, it falls back to using
instanceof.
I missed this in the 0.2.0 release and did not notice in code I've been
writing using traits because the test cases are executed by Node. Sorry to
anyone who may have had trouble client-side.
This reverts commit 58ee52ad4a.
As it turns out, IE9 allows use of instanceof with special object types, not
just functions. One such example is HTMLElement; its type is `object', whereas
in Firefox and Chromium it is `function'. There is no reliable way to perform
this detection.
Therefore, the try/catch here is more reliable.
I feel like I originally did this because older versions of node didn't like
relative paths (unless maybe the cwd wasn't in NODE_PATH). Regardless, it works
now, and this is cleaner.
Further, I noticed that __dirname didn't seem to be working properly with
browserify. While GNU ease.js does not make use of it (ease.js uses its own
scripts), other projects may.
Members with an underscore prefix are now implicitly private, which follows
conventions established in many object-oriented languages. This allows for a
concise definition style familiar to prototypal (and I suppose Ruby)
programmers.
These are the beginning of some smaller performance optimizations brought on
by the v8 profiler. This includes removal or movement of over-reaching
try/catch blocks and more disciplined argument handling, neither of which
can be compiled into machine code (permanently, at least). This also removes
some unneeded code, adds some baseline performance test cases, and begins
generic performance test output and HTML generation which will be used in
the future for more detailed analysis.
This is just a starting point; there's more to come, guided by profiling.
The trait implementation needs some love and, since its development is not
yet complete, that will be optimized in the near future. Further, there are
additional optimizations that can be made when ease.js recognizes that
certain visibility layers are unneeded, allowing it to create more
lightweight classes.
Performance enhancements will also introduce the ability to generate a
``compiled'' class, which will generate a prototype that can be immediately
run without the overhead of processing keywords, etc. This will also have
the benefit of generating code that can be understood by static analysis
tools and, consequently, optimizers.
All in good time.
`make perf` will build, by default, perf.log, but you may also build perf.*;
for example:
$ make perf.1
# make some changes
$ make perf.2
This allows comparing changes easily.
Styled for display to user as the tests are running, but data are written to
perf.out for additional processing.
You can style the perf.out file cleanly using:
$ column -ts\| perf.out
This check was originally added because IE8's implementation is broken.
However, we already perform a test in the `can_define_prop` configuration,
so this is not necessary (it seems to be a relic).
Copyright for the GNU ease.js project has been assigned to the Free Software
Foundation. This allows the FSF to enforce the project licenses, which is
something that I lack the time and money to do. It further ensures, through
the contract I signed with the FSF, that all distrbutions of GNU ease.js,
and all derivatives, will always ``be on terms that explicitly and
perpetually permit anyone possessing a copy of the work to which the terms
apply, and possessing accurate notice of these terms, to redistribute copies
of the work to anyone on the same terms'' and that the project ``shall be
offered in the form of machine-readable source code''.
Consequently, any contributors to the project (aside from changes deemed to
be trivial) will be required to assign copyright to the FSF; this puts GNU
ease.js on a firm legal ground to prevent complicating enforcement.
Contributors can rest assured that the code they contribute will always
remain free (as in freedom).
I thank Donald Robertson III of the FSF for his help and guidance during
this process.
This is an exciting performance optimization that seems to have eluded me
for a surprisingly long time, given that the realization was quite random.
ease.js accomplishes much of its work through a method wrapper---each and
every method definition (well, until now) was wrapped in a closure that
performed a number of steps, depending on the type of wrapper involved:
1. All wrappers perform a context lookup, binding to the instance's private
member object of the class that defined that particular method. (See
"Implementation Details" in the manual for more information.)
2. This context is restored upon returning from the call: if a method
returns `this', it is instead converted back to the context in which
the method was invoked, which prevents the private member object from
leaking out of a public interface.
3. In the event of an override, this.__super is set up (and torn down).
There are other details (e.g. the method wrapper used for method proxies),
but for the sake of this particular commit, those are the only ones that
really matter. There are a couple of important details to notice:
- Private members are only ever accessible from within the context of the
private member object, which is always the context when executing a
method.
- Private methods cannot be overridden, as they cannot be inherited.
Consequently:
1. We do not need to perform a context lookup: we are already in the proper
context.
2. We do not need to restore the context, as we never needed to change it
to begin with.
3. this.__super is never applicable.
Method wrappers are therefore never necessary for private methods; they have
therefore been removed.
This has some interesting performance implications. While in most cases the
overhead of method wrapping is not a bottleneck, it can have a strong impact
in the event of frequent method calls or heavily recursive algorithms. There
was one particular problem that ease.js suffered from, which is mentioned in
the manual: recursive calls to methods in ease.js were not recommended
because it
(a) made two function calls for each method call, effectively halving the
remaining call stack size, and
(b) tail call optimization could not be performed, because recursion
invoked the wrapper, *not* the function that was wrapped.
By removing the method wrapper on private methods, we solve both of these
problems; now, heavily recursive algorithms need only use private methods
(which could always be exposed through a protected or public API) when
recursing to entirely avoid any performance penalty by using ease.js.
Running the test cases on my system (your results may vary) before and after
the patch, we have:
BEFORE:
0.170s (x1000 = 0.0001700000s each): Declare 1000 anonymous classes with
private members
0.021s (x500000 = 0.0000000420s each): Invoke private methods internally
AFTER:
0.151s (x1000 = 0.0001510000s each): Declare 1000 anonymous classes with
private members
0.004s (x500000 = 0.0000000080s each): Invoke private methods internally
This is all the more motivation to use private members, which enforces
encapsulation; keep in mind that, because use of private members is the
ideal in well-encapsulated and well-factored code, ease.js has been designed
to perform best under those circumstances.
Mike Gerwitz