Existing functionality is maintained using toString. This is necessary to
support type checking, and to be more consistent with the native Symbol
implementation.
Technically `new FallbackSymbol` is supposed to throw a TypeError, just as
`new Symbol` would, but doing so complicates the constructor unncessarily,
so I am not going to bother with that here.
This is a security-related issue: we want to ensure that the user cannot,
without debugging tools, retrieve certain internal details that may be used
to compromise an implementation.
This will, at least in ES5 environments, prevent its general discovery and
[accidental] use. Of course, any decent debugger will still be able to see
it, so unless ES6 is used, this is not truely hidden.
I do not wholly recall why this was done initially (nor do I care to
research it, since it's not necessary now), but from the looks of it, it was
likely a kluge to handle a poor implementation of some feature.
This will help clean up a little, since it's rude to pollute a prototype
unnecessarily.
Temporary method removed and symbol now provided directly to the trait ctor;
this is needed to retrieve the protected visibility object; there is
currently no API for doing so, and there may never be (providing an API for
such a thing seems questionable).
Of course, if we eventually want to decouple the trait implementation from
ClassBuilder (which would be a good idea), we'll have to figure out
something.
Note that this patch temporarily breaks encapsulation via
ClassBuilder.___$$privsym$$ to expose necessary internal details to Trait;
this will be resolved.
This is the closest we will get to implementing a concept similar to symbols
in pre-ES6. The intent is that, in an ES5 environment, the caller should
ensure that the object receiving this key will mark it as non-enumerable.
Otherwise, we're out of luck.
The symbol string is pseduo-randomly generated with an attempt to reduce the
likelihood of field collisions and malicious Math.{floor,random} overwrites
(so long as they are clean at the time of loading the module).
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 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.
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.
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.
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).
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.
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.
Mike Gerwitz