2011-08-14 18:47:48 -04:00
|
|
|
/**
|
|
|
|
* Handles building members (properties, methods)
|
|
|
|
*
|
2011-08-27 17:08:05 -04:00
|
|
|
* This prototype could have easily been refactored into a number of others
|
|
|
|
* (e.g. one for each type of member), but that refactoring has been deferred
|
|
|
|
* until necessary to ensure ease.js maintains a relatively small footprint.
|
|
|
|
* Ultimately, however, such a decision is a micro-optimization and shouldn't
|
|
|
|
* harm the design and maintainability of the software.
|
|
|
|
*
|
2011-11-04 23:08:41 -04:00
|
|
|
* TODO: Implementation is inconsistent between various members. For example,
|
|
|
|
* methods use ___$$keywords$$, whereas properties use [ val, keywords ]. Decide
|
|
|
|
* on a common format.
|
|
|
|
*
|
2013-12-22 08:53:10 -05:00
|
|
|
* Copyright (C) 2010, 2011, 2012, 2013 Mike Gerwitz
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* This file is part of ease.js.
|
|
|
|
*
|
|
|
|
* ease.js is free software: you can redistribute it and/or modify it under the
|
Relicensed under the GPLv3+
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.
2013-12-20 01:00:35 -05:00
|
|
|
* terms of the GNU General Public License as published by the Free Software
|
|
|
|
* Foundation, either version 3 of the License, or (at your option) any later
|
|
|
|
* version.
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
Relicensed under the GPLv3+
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.
2013-12-20 01:00:35 -05:00
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
Relicensed under the GPLv3+
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.
2013-12-20 01:00:35 -05:00
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* @author Mike Gerwitz
|
|
|
|
*/
|
|
|
|
|
2011-10-22 00:32:59 -04:00
|
|
|
var util = require( __dirname + '/util' ),
|
|
|
|
Warning = require( __dirname + '/warn' ).Warning,
|
2011-11-02 23:28:23 -04:00
|
|
|
visibility = [ 'public', 'protected', 'private' ]
|
2011-08-14 18:47:48 -04:00
|
|
|
;
|
|
|
|
|
|
|
|
|
2011-08-27 17:08:05 -04:00
|
|
|
/**
|
|
|
|
* Responsible for building class members
|
2011-12-13 21:19:14 -05:00
|
|
|
*
|
|
|
|
* @param {Function} wrap_method method wrapper
|
|
|
|
* @param {Function} wrap_override method override wrapper
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
* @param {Function} wrap_proxy method proxy wrapper
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {MemberBuilderValidator} validate member validator
|
|
|
|
*
|
|
|
|
* @constructor
|
2011-08-27 17:08:05 -04:00
|
|
|
*/
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
module.exports = function MemberBuilder(
|
|
|
|
wrap_method, wrap_override, wrap_proxy, validate
|
|
|
|
)
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
|
|
|
// permit omitting 'new' keyword
|
|
|
|
if ( !( this instanceof module.exports ) )
|
|
|
|
{
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
return new module.exports(
|
|
|
|
wrap_method, wrap_override, wrap_proxy, validate
|
|
|
|
);
|
2011-08-14 18:47:48 -04:00
|
|
|
}
|
2011-08-31 00:24:19 -04:00
|
|
|
|
|
|
|
this._wrapMethod = wrap_method;
|
|
|
|
this._wrapOverride = wrap_override;
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
this._wrapProxy = wrap_proxy;
|
2011-10-22 01:00:17 -04:00
|
|
|
|
2011-10-23 00:43:08 -04:00
|
|
|
this._validate = validate;
|
2011-08-14 18:47:48 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
// we're throwing everything into the prototype
|
|
|
|
exports = module.exports.prototype;
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Initializes member object
|
|
|
|
*
|
|
|
|
* The member object contains members for each level of visibility (public,
|
|
|
|
* protected and private).
|
|
|
|
*
|
|
|
|
* @param {Object} mpublic default public members
|
|
|
|
* @param {Object} mprotected default protected members
|
|
|
|
* @param {Object} mprivate default private members
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @return {__visobj}
|
2011-08-14 18:47:48 -04:00
|
|
|
*/
|
|
|
|
exports.initMembers = function( mpublic, mprotected, mprivate )
|
|
|
|
{
|
|
|
|
return {
|
|
|
|
'public': mpublic || {},
|
|
|
|
'protected': mprotected || {},
|
|
|
|
'private': mprivate || {},
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Copies a method to the appropriate member prototype, depending on
|
|
|
|
* visibility, and assigns necessary metadata from keywords
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {__visobj} members
|
|
|
|
* @param {!Object} meta metadata container
|
|
|
|
* @param {string} name property name
|
|
|
|
* @param {*} value property value
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {!Object.<boolean>} keywords parsed keywords
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {Function} instCallback function to call in order to retrieve
|
|
|
|
* object to bind 'this' keyword to
|
|
|
|
*
|
|
|
|
* @param {number} cid class id
|
|
|
|
* @param {Object=} base optional base object to scan
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* @return {undefined}
|
|
|
|
*/
|
|
|
|
exports.buildMethod = function(
|
|
|
|
members, meta, name, value, keywords, instCallback, cid, base
|
|
|
|
)
|
|
|
|
{
|
|
|
|
// TODO: We can improve performance by not scanning each one individually
|
|
|
|
// every time this method is called
|
|
|
|
var prev_data = scanMembers( members, name, base ),
|
|
|
|
prev = ( prev_data ) ? prev_data.member : null,
|
|
|
|
prev_keywords = ( prev && prev.___$$keywords$$ ),
|
2011-10-25 23:30:57 -04:00
|
|
|
dest = getMemberVisibility( members, keywords, name );
|
2011-08-14 18:47:48 -04:00
|
|
|
;
|
|
|
|
|
|
|
|
// ensure that the declaration is valid (keywords make sense, argument
|
|
|
|
// length, etc)
|
2011-10-22 01:00:17 -04:00
|
|
|
this._validate.validateMethod(
|
|
|
|
name, value, keywords, prev_data, prev_keywords
|
|
|
|
);
|
2011-08-14 18:47:48 -04:00
|
|
|
|
|
|
|
// we might be overriding an existing method
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
if ( keywords[ 'proxy' ] )
|
|
|
|
{
|
2012-05-03 14:13:47 -04:00
|
|
|
// TODO: Note that this is not compatible with method hiding, due to its
|
|
|
|
// positioning (see hideMethod() below); address once method hiding is
|
|
|
|
// implemented (the validators currently handle everything else)
|
|
|
|
dest[ name ] = this._createProxy(
|
|
|
|
value, instCallback, cid, name, keywords
|
|
|
|
);
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
}
|
|
|
|
else if ( prev )
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
|
|
|
|
|
|
|
if ( keywords[ 'override' ] || prev_keywords[ 'abstract' ] )
|
|
|
|
{
|
|
|
|
// override the method
|
2011-08-31 00:24:19 -04:00
|
|
|
dest[ name ] = this._overrideMethod(
|
|
|
|
prev, value, instCallback, cid
|
|
|
|
);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// by default, perform method hiding, even if the keyword was not
|
|
|
|
// provided (the keyword simply suppresses the warning)
|
|
|
|
dest[ name ] = hideMethod( prev, value, instCallback, cid );
|
2011-08-14 18:47:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
else if ( keywords[ 'abstract' ] )
|
|
|
|
{
|
|
|
|
// we do not want to wrap abstract methods, since they are not callable
|
|
|
|
dest[ name ] = value;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// we are not overriding the method, so simply copy it over, wrapping it
|
|
|
|
// to ensure privileged calls will work properly
|
2011-09-02 22:37:13 -04:00
|
|
|
dest[ name ] = this._overrideMethod( null, value, instCallback, cid );
|
2011-08-14 18:47:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
// store keywords for later reference (needed for pre-ES5 fallback)
|
|
|
|
dest[ name ].___$$keywords$$ = keywords;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Copies a property to the appropriate member prototype, depending on
|
|
|
|
* visibility, and assigns necessary metadata from keywords
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {__visobj} members
|
|
|
|
* @param {!Object} meta metadata container
|
|
|
|
* @param {string} name property name
|
|
|
|
* @param {*} value property value
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {!Object.<boolean>} keywords parsed keywords
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* @param {Object=} base optional base object to scan
|
|
|
|
*
|
|
|
|
* @return {undefined}
|
|
|
|
*/
|
|
|
|
exports.buildProp = function( members, meta, name, value, keywords, base )
|
|
|
|
{
|
|
|
|
// TODO: We can improve performance by not scanning each one individually
|
|
|
|
// every time this method is called
|
2011-10-23 00:43:08 -04:00
|
|
|
var prev_data = scanMembers( members, name, base ),
|
|
|
|
prev = ( prev_data ) ? prev_data.member : null,
|
|
|
|
prev_keywords = ( prev ) ? prev[ 1 ] : null;
|
2011-08-14 18:47:48 -04:00
|
|
|
|
2011-10-23 00:43:08 -04:00
|
|
|
this._validate.validateProperty(
|
|
|
|
name, value, keywords, prev_data, prev_keywords
|
|
|
|
);
|
2011-08-14 18:47:48 -04:00
|
|
|
|
2011-10-25 23:30:57 -04:00
|
|
|
getMemberVisibility( members, keywords, name )[ name ] =
|
|
|
|
[ value, keywords ];
|
2011-08-14 18:47:48 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-10-29 07:47:15 -04:00
|
|
|
/**
|
|
|
|
* Copies a getter/setter to the appropriate member prototype, depending on
|
|
|
|
* visibility, and assigns necessary metadata from keywords
|
|
|
|
*
|
'this' now properly binds to the private member object of the instance for getters/setters
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.)
2013-01-19 20:54:30 -05:00
|
|
|
* TODO: This should essentially mirror buildMethod with regards to overrides,
|
|
|
|
* proxies, etc.
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {!__visobj} members
|
|
|
|
* @param {!Object} meta metadata container
|
|
|
|
* @param {string} name getter name
|
|
|
|
* @param {*} get getter value
|
|
|
|
* @param {*} set setter value
|
2011-10-29 07:47:15 -04:00
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {!Object.<boolean>} keywords parsed keywords
|
2011-10-29 07:47:15 -04:00
|
|
|
*
|
'this' now properly binds to the private member object of the instance for getters/setters
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.)
2013-01-19 20:54:30 -05:00
|
|
|
* @param {Function} instCallback function to call in order to retrieve
|
|
|
|
* object to bind 'this' keyword to
|
|
|
|
*
|
|
|
|
* @param {number} cid class id
|
2011-10-29 07:47:15 -04:00
|
|
|
* @param {Object=} base optional base object to scan
|
|
|
|
*
|
|
|
|
* @return {undefined}
|
2011-12-13 21:19:14 -05:00
|
|
|
*
|
|
|
|
* Closure Compiler is improperly throwing warnings on Object.defineProperty():
|
|
|
|
* @suppress {checkTypes}
|
2011-10-29 07:47:15 -04:00
|
|
|
*/
|
2011-10-29 08:23:59 -04:00
|
|
|
exports.buildGetterSetter = function(
|
'this' now properly binds to the private member object of the instance for getters/setters
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.)
2013-01-19 20:54:30 -05:00
|
|
|
members, meta, name, get, set, keywords, instCallback, cid, base
|
2011-10-29 07:47:15 -04:00
|
|
|
)
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
2011-10-30 12:06:09 -04:00
|
|
|
var prev_data = scanMembers( members, name, base ),
|
2011-12-03 00:30:22 -05:00
|
|
|
prev_keywords = ( ( prev_data && prev_data.get )
|
|
|
|
? prev_data.get.___$$keywords$$
|
|
|
|
: null
|
|
|
|
)
|
2011-10-30 12:06:09 -04:00
|
|
|
;
|
2011-10-28 00:08:22 -04:00
|
|
|
|
|
|
|
this._validate.validateGetterSetter(
|
2011-11-05 09:40:56 -04:00
|
|
|
name, {}, keywords, prev_data, prev_keywords
|
2011-10-28 00:08:22 -04:00
|
|
|
);
|
|
|
|
|
'this' now properly binds to the private member object of the instance for getters/setters
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.)
2013-01-19 20:54:30 -05:00
|
|
|
if ( get )
|
|
|
|
{
|
|
|
|
get = this._overrideMethod( null, get, instCallback, cid );
|
|
|
|
|
|
|
|
// ensure we store the keywords *after* the override, otherwise they
|
|
|
|
// will be assigned to the wrapped function (the getter)
|
|
|
|
get.___$$keywords$$ = keywords;
|
|
|
|
}
|
2011-12-03 00:30:22 -05:00
|
|
|
|
2011-08-14 18:47:48 -04:00
|
|
|
Object.defineProperty(
|
2011-10-27 20:44:25 -04:00
|
|
|
getMemberVisibility( members, keywords, name ),
|
2011-08-14 18:47:48 -04:00
|
|
|
name,
|
2011-10-29 08:23:59 -04:00
|
|
|
{
|
|
|
|
get: get,
|
'this' now properly binds to the private member object of the instance for getters/setters
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.)
2013-01-19 20:54:30 -05:00
|
|
|
set: ( set )
|
|
|
|
? this._overrideMethod( null, set, instCallback, cid )
|
|
|
|
: set,
|
|
|
|
|
2011-10-29 08:23:59 -04:00
|
|
|
enumerable: true,
|
|
|
|
configurable: false,
|
|
|
|
}
|
2011-08-14 18:47:48 -04:00
|
|
|
);
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns member prototype to use for the requested visibility
|
|
|
|
*
|
2011-10-25 23:30:57 -04:00
|
|
|
* Will throw an exception if multiple access modifiers were used.
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {__visobj} members
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {!Object.<boolean>} keywords parsed keywords
|
|
|
|
* @param {string} name member name
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* @return {Object} reference to visibility of members argument to use
|
|
|
|
*/
|
2011-10-25 23:30:57 -04:00
|
|
|
function getMemberVisibility( members, keywords, name )
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
|
|
|
var viserr = function()
|
|
|
|
{
|
|
|
|
throw TypeError(
|
2011-10-25 23:30:57 -04:00
|
|
|
"Only one access modifier may be used for definition of '" +
|
|
|
|
name + "'"
|
2011-08-14 18:47:48 -04:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
// there's cleaner ways of doing this, but consider it loop unrolling for
|
|
|
|
// performance
|
|
|
|
if ( keywords[ 'private' ] )
|
|
|
|
{
|
|
|
|
( keywords[ 'public' ] || keywords[ 'protected' ] ) && viserr();
|
|
|
|
return members[ 'private' ];
|
|
|
|
}
|
|
|
|
else if ( keywords[ 'protected' ] )
|
|
|
|
{
|
|
|
|
( keywords[ 'public' ] || keywords[ 'private' ] ) && viserr();
|
|
|
|
return members[ 'protected' ];
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// public keyword is the default, so explicitly specifying it is only
|
|
|
|
// for clarity
|
|
|
|
( keywords[ 'private' ] || keywords[ 'protected' ] ) && viserr();
|
|
|
|
return members[ 'public' ];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Scan each level of visibility for the requested member
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {__visobj} members
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* @param {string} name member to locate
|
|
|
|
* @param {Object=} base optional base object to scan
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @return {{get,set,member}|null}
|
2011-08-14 18:47:48 -04:00
|
|
|
*/
|
|
|
|
function scanMembers( members, name, base )
|
|
|
|
{
|
|
|
|
var i = visibility.length,
|
|
|
|
member = null;
|
|
|
|
|
|
|
|
// locate requested member by scanning each level of visibility
|
|
|
|
while ( i-- )
|
|
|
|
{
|
|
|
|
var visobj = members[ visibility[ i ] ];
|
|
|
|
|
|
|
|
// In order to support getters/setters, we must go off of the
|
|
|
|
// descriptor. We must also ignore base properties (last argument), such
|
|
|
|
// as Object.prototype.toString(). However, we must still traverse the
|
|
|
|
// prototype chain.
|
|
|
|
if ( member = util.getPropertyDescriptor( visobj, name, true ) )
|
|
|
|
{
|
|
|
|
return {
|
|
|
|
get: member.get,
|
|
|
|
set: member.set,
|
|
|
|
member: member.value,
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// if a second comparison object was given, try again using it instead of
|
|
|
|
// the original members object
|
|
|
|
if ( base !== undefined )
|
|
|
|
{
|
|
|
|
var base_methods = base.___$$methods$$,
|
|
|
|
base_props = base.___$$props$$;
|
|
|
|
|
|
|
|
// scan the base's methods and properties, if they are available
|
|
|
|
return ( base_methods && scanMembers( base_methods, name ) )
|
|
|
|
|| ( base_props && scanMembers( base_props, name ) )
|
|
|
|
|| null
|
|
|
|
;
|
|
|
|
}
|
|
|
|
|
|
|
|
// nothing was found
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Hide a method with a "new" method
|
|
|
|
*/
|
|
|
|
function hideMethod( super_method, new_method, instCallback, cid )
|
|
|
|
{
|
|
|
|
// TODO: This function is currently unimplemented. It exists at present to
|
|
|
|
// provide a placeholder and ensure that the override keyword is required to
|
|
|
|
// override a parent method.
|
2011-10-22 13:57:17 -04:00
|
|
|
//
|
|
|
|
// We should never get to this point if the default validation rule set is
|
|
|
|
// used to prevent omission of the 'override' keyword.
|
|
|
|
throw Error(
|
|
|
|
'Method hiding not yet implemented (we should never get here; bug).'
|
|
|
|
);
|
2011-08-14 18:47:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
/**
|
|
|
|
* Create a method that proxies to the method of another object
|
|
|
|
*
|
|
|
|
* @param {string} proxy_to name of property (of instance) to proxy to
|
|
|
|
*
|
|
|
|
* @param {Function} instCallback function to call in order to retrieve
|
|
|
|
* object to bind 'this' keyword to
|
|
|
|
*
|
2012-05-03 14:13:47 -04:00
|
|
|
* @param {number} cid class id
|
|
|
|
* @param {string} mname name of method to invoke on destination object
|
|
|
|
* @param {Object} keywords method keywords
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
*
|
|
|
|
* @return {Function} proxy method
|
|
|
|
*/
|
2012-05-03 14:13:47 -04:00
|
|
|
exports._createProxy = function( proxy_to, instCallback, cid, mname, keywords )
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
{
|
|
|
|
return this._wrapProxy.wrapMethod(
|
2012-05-03 14:13:47 -04:00
|
|
|
proxy_to, null, cid, instCallback, mname, keywords
|
Added `proxy' keyword support
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.
2012-05-02 13:26:47 -04:00
|
|
|
);
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-08-14 18:47:48 -04:00
|
|
|
/**
|
|
|
|
* Generates a method override function
|
|
|
|
*
|
|
|
|
* The override function simply wraps the method so that its invocation will
|
|
|
|
* pass a __super property. This property may be used to invoke the overridden
|
|
|
|
* method.
|
|
|
|
*
|
|
|
|
* @param {function()} super_method method to override
|
|
|
|
* @param {function()} new_method method to override with
|
|
|
|
*
|
2011-12-13 21:19:14 -05:00
|
|
|
* @param {Function} instCallback function to call in order to retrieve
|
|
|
|
* object to bind 'this' keyword to
|
|
|
|
*
|
|
|
|
* @param {number} cid class id
|
2011-08-14 18:47:48 -04:00
|
|
|
*
|
|
|
|
* @return {function()} override method
|
|
|
|
*/
|
2011-08-31 00:24:19 -04:00
|
|
|
exports._overrideMethod = function(
|
|
|
|
super_method, new_method, instCallback, cid
|
|
|
|
)
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
|
|
|
instCallback = instCallback || function() {};
|
|
|
|
|
|
|
|
// return a function that permits referencing the super method via the
|
|
|
|
// __super property
|
|
|
|
var override = null;
|
|
|
|
|
2011-09-02 22:37:13 -04:00
|
|
|
// are we overriding?
|
2011-08-31 00:24:19 -04:00
|
|
|
override = (
|
2011-09-02 22:37:13 -04:00
|
|
|
( super_method )
|
|
|
|
? this._wrapOverride
|
|
|
|
: this._wrapMethod
|
2011-08-31 00:24:19 -04:00
|
|
|
).wrapMethod( new_method, super_method, cid, instCallback );
|
2011-08-14 18:47:48 -04:00
|
|
|
|
|
|
|
// This is a trick to work around the fact that we cannot set the length
|
|
|
|
// property of a function. Instead, we define our own property - __length.
|
|
|
|
// This will store the expected number of arguments from the super method.
|
|
|
|
// This way, when a method is being overridden, we can check to ensure its
|
|
|
|
// compatibility with its super method.
|
|
|
|
util.defineSecureProp( override,
|
|
|
|
'__length',
|
2011-09-02 22:37:13 -04:00
|
|
|
( new_method.__length || new_method.length )
|
2011-08-14 18:47:48 -04:00
|
|
|
);
|
|
|
|
|
|
|
|
return override;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return the visibility level as a numeric value, where 0 is public and 2 is
|
|
|
|
* private
|
|
|
|
*
|
|
|
|
* @param {Object} keywords keywords to scan for visibility level
|
|
|
|
*
|
|
|
|
* @return {number} visibility level as a numeric value
|
|
|
|
*/
|
2011-10-14 22:14:29 -04:00
|
|
|
exports._getVisibilityValue = function( keywords )
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
2011-10-22 00:32:59 -04:00
|
|
|
if ( keywords[ 'protected' ] )
|
2011-08-14 18:47:48 -04:00
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else if ( keywords[ 'private' ] )
|
|
|
|
{
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// default is public
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|