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.
This tool can help to ensure that commits have not been falsely authored. For
example, if you receive an ease.js repository from a friend, there is no way to
verify that a commit from "Mike Gerwitz" is actually a commit from myself unless
it has been signed using my private key. This additional check will help to
ensure the integrity of the repository.
Please note that automated systems should *not* invoke this utility directly
from this repository, unless it is invoked using a previously trusted commit.
Otherwise, an attacker need only alter the script to competely evade the check.
After dealing with autoconf, I may decide not to implement it. The build process
is fairly simple as it is and I do not want to over-complicate it. verset solves
one of the issues that autconf would have aided in addressing - setting a
version number.
- 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.
Growing much closer to releasing. Hopefully in the next couple of days; I just
don't want to rush it. Though, at the same time, I've been noticing projects
popping up with very similar / exact names to this one. A project named "ease"
was added to the npm repository and another "ease.js" is on GitHub, although
it's made no progress. As such, I want to ensure I reserve the name in npm.
I've been testing the new library and work and noticed only a couple minor
issues, primiarly due to misuse of the library. Looking good.
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.
This is nothing against uglify. Rather, here's the story on this:
Commit e4cd1e fixed an error that was causing minified files to break in IE.
This was due to how IE interprets things, not how UglifyJS was minifying them.
Indeed, Closure Compiler had the exact same problem.
The decision to move to Closure Compiler was due to a variety of factors, which
came down to primarily feature set and tests. Closure Compiler is well tested
and maintained. It also includes a number of additional, beneficial features.
UglifyJS is an excellent project and I would recommend it to anyone, but it is
not tested (no unit tests; it's tested by ensuring common libraries like jQuery
run after minification). It is, however, significantly faster.
It's likely that, in the future, once I add autoconf for the build process to
configure certain settings, that I will add UglifyJS as an option. I'm sure many
people would prefer that, especially those who dislike Java and do not wish to
have it installed. Hopefully those that do decide to install Java will go with
openjdk, not Oracle's proprietary implementation.
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