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.
I'm unsure as to why I originally placed them in separate methods. propParse() will
always find a getter at the same time it finds a setter, and vice versa, should they
both have been defined on the object.
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
Ironic, considering the current refactoring (not yet committed) of MemberBuilder to split validation logic into MemberBuilderValidator was partially to be able to easily override the fallback logic. It's a useful refactoring nonetheless, but it could have waited.
As mentioned in a prior commit blog-like entry, many of the tests evolved into more of an integration or system-level type of test. Let's get away from that.
Mike Gerwitz