phaser/3.0.0/merge/core/SignalBinding.js

200 lines
5.6 KiB
JavaScript
Raw Normal View History

2013-10-01 12:54:29 +00:00
/**
* @author Miller Medeiros http://millermedeiros.github.com/js-signals/
2013-10-01 12:54:29 +00:00
* @author Richard Davey <rich@photonstorm.com>
2016-04-04 21:15:01 +00:00
* @copyright 2016 Photon Storm Ltd.
2013-10-01 12:54:29 +00:00
* @license {@link https://github.com/photonstorm/phaser/blob/master/license.txt|MIT License}
*/
/**
* Object that represents a binding between a Signal and a listener function.
2014-07-02 14:25:07 +00:00
* This is an internal constructor and shouldn't be created directly.
2013-11-28 15:57:09 +00:00
* Inspired by Joa Ebert AS3 SignalBinding and Robert Penner's Slot classes.
*
* @class Phaser.SignalBinding
* @constructor
2013-11-28 15:57:09 +00:00
* @param {Phaser.Signal} signal - Reference to Signal object that listener is currently bound to.
2013-10-01 12:54:29 +00:00
* @param {function} listener - Handler function bound to the signal.
2013-10-01 15:39:39 +00:00
* @param {boolean} isOnce - If binding should be executed just once.
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
* @param {object} [listenerContext=null] - Context on which listener will be executed (object that should represent the `this` variable inside listener function).
2013-10-01 12:54:29 +00:00
* @param {number} [priority] - The priority level of the event listener. (default = 0).
* @param {...any} [args=(none)] - Additional arguments to pass to the callback (listener) function. They will be appended after any arguments usually dispatched.
*/
Phaser.SignalBinding = function (signal, listener, isOnce, listenerContext, priority, args) {
/**
* @property {Phaser.Game} _listener - Handler function bound to the signal.
* @private
*/
this._listener = listener;
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
if (isOnce)
{
this._isOnce = true;
}
if (listenerContext != null) /* not null/undefined */
{
this.context = listenerContext;
}
/**
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
* @property {Phaser.Signal} _signal - Reference to Signal object that listener is currently bound to.
* @private
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
this._signal = signal;
if (priority)
{
this._priority = priority;
}
if (args && args.length)
{
this._args = args;
}
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
};
Phaser.SignalBinding.prototype = {
/**
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
* @property {?object} context - Context on which listener will be executed (object that should represent the `this` variable inside listener function).
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
context: null,
/**
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
* @property {boolean} _isOnce - If binding should be executed just once.
* @private
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
_isOnce: false,
/**
* @property {number} _priority - Listener priority.
* @private
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
_priority: 0,
/**
* @property {array} _args - Listener arguments.
* @private
*/
_args: null,
/**
* @property {number} callCount - The number of times the handler function has been called.
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
callCount: 0,
/**
2013-10-01 12:54:29 +00:00
* If binding is active and should be executed.
2013-10-01 15:39:39 +00:00
* @property {boolean} active
2013-10-01 12:54:29 +00:00
* @default
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
active: true,
/**
2013-10-01 12:54:29 +00:00
* Default parameters passed to listener during `Signal.dispatch` and `SignalBinding.execute` (curried parameters).
2014-03-23 07:59:28 +00:00
* @property {array|null} params
* @default
2013-10-01 12:54:29 +00:00
*/
Signal - memory optimization / reductions There are a fair amount of Signal objects created. In the current implementation these are somewhat "fat" objects for two reasons: - A closure / ad-hoc `dispatch` is created for each new Signal - this increases the retained size by 138+ bytes/Signal in Chrome. - There are a number of instance variables that never change from their default value, and the bindings array is always created, even if never used. This change "lightens" the Signals such that there is significantly less penalty for having many (unusued) signals. As an example of how much this _does_ play a role, in the "Random Sprite" demo ~2000 Signals are created, with only 12 of these signals being subscribed to. This results in a shallow size of ~300K and a retained size of ~600K (which is almost as much memory as required by the Sprites/Sprites themselves!) for .. nothing. With these changes the shallow and retained sizes are less than 50K each - and this is with only ~200 sprites! This change addresses these issues by - Changing it so there is _no_ `dispatch` closure created. This is a _breaking change_ (although there is no usage of such in core where it breaks); the code referenced "#24", but no such issue could be found on github. In the rare case that code needs to obtain a dispatch-closure, the `boundDispatch` property can be used to trivially obtain a (cached) closure. - The properties and default values are moved into the prototype; and the `_bindings` array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals. This is minor breaking change, as per the removal of the automatic closure; but no such need/usage was found in the core. (There may be cases in the examples, which were not checked.) If merely opting for the array creation delay and keeping the default properties in the prototype the shallow size is still halved; less significant but still a consideration.
2014-11-24 12:37:24 +00:00
params: null,
/**
2013-10-01 12:54:29 +00:00
* Call listener passing arbitrary parameters.
2013-11-28 15:57:09 +00:00
* If binding was added using `Signal.addOnce()` it will be automatically removed from signal dispatch queue, this method is used internally for the signal dispatch.
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#execute
* @param {any[]} [paramsArr] - Array of parameters that should be passed to the listener.
2013-11-28 15:57:09 +00:00
* @return {any} Value returned by the listener.
2013-10-01 12:54:29 +00:00
*/
2014-03-23 08:29:04 +00:00
execute: function(paramsArr) {
var handlerReturn, params;
if (this.active && !!this._listener)
{
2014-03-23 08:29:04 +00:00
params = this.params ? this.params.concat(paramsArr) : paramsArr;
if (this._args)
{
params = params.concat(this._args);
}
handlerReturn = this._listener.apply(this.context, params);
this.callCount++;
if (this._isOnce)
{
this.detach();
}
}
return handlerReturn;
},
/**
2013-10-01 12:54:29 +00:00
* Detach binding from signal.
2013-11-28 15:57:09 +00:00
* alias to: @see mySignal.remove(myBinding.getListener());
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#detach
2013-10-01 12:54:29 +00:00
* @return {function|null} Handler function bound to the signal or `null` if binding was previously detached.
*/
detach: function () {
return this.isBound() ? this._signal.remove(this._listener, this.context) : null;
},
/**
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#isBound
2013-10-01 15:39:39 +00:00
* @return {boolean} True if binding is still bound to the signal and has a listener.
2013-10-01 12:54:29 +00:00
*/
isBound: function () {
return (!!this._signal && !!this._listener);
},
/**
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#isOnce
2013-10-01 15:39:39 +00:00
* @return {boolean} If SignalBinding will only be executed once.
2013-10-01 12:54:29 +00:00
*/
isOnce: function () {
return this._isOnce;
},
/**
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#getListener
2014-10-21 22:08:16 +00:00
* @return {function} Handler function bound to the signal.
2013-10-01 12:54:29 +00:00
*/
getListener: function () {
return this._listener;
},
/**
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#getSignal
2014-10-21 22:08:16 +00:00
* @return {Phaser.Signal} Signal that listener is currently bound to.
2013-10-01 12:54:29 +00:00
*/
getSignal: function () {
return this._signal;
},
/**
2013-10-01 12:54:29 +00:00
* Delete instance properties
2014-07-02 14:25:07 +00:00
* @method Phaser.SignalBinding#_destroy
2013-10-01 12:54:29 +00:00
* @private
*/
_destroy: function () {
delete this._signal;
delete this._listener;
delete this.context;
},
/**
2013-10-02 10:22:20 +00:00
* @method Phaser.SignalBinding#toString
2013-10-01 12:54:29 +00:00
* @return {string} String representation of the object.
*/
toString: function () {
return '[Phaser.SignalBinding isOnce:' + this._isOnce +', isBound:'+ this.isBound() +', active:' + this.active + ']';
}
};
Phaser.SignalBinding.prototype.constructor = Phaser.SignalBinding;