Skip to content

Conversation

@darkwing
Copy link
Contributor

@darkwing darkwing commented Aug 12, 2016

One idea I had and have seen before is, instead of this.blah, this all the time, doing 'blah', this and assuming that this holds the function if the first argument is a string. i.e:

module.exports.bind = function (fn, ctx) {
  if(typeof fn === 'string') fn = ctx[fn];
  return function bound () {
    return fn.apply(ctx, arguments);
  };
};

bind('onKeyUp', this);

@ngokevin
Copy link
Member

Can we get some unit test coverage on it?

@darkwing
Copy link
Contributor Author

Yep; left off late at night. Will add tests today!

module.exports.debug = require('./debug');
module.exports.entity = require('./entity');
module.exports.forceCanvasResizeSafariMobile = require('./forceCanvasResizeSafariMobile');
module.exports.functions = require('./functions');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually might be more consistent to have this as function rather than functions. (I imagine we'd have object and we already have entity). Hopefully not too much hassle to replace.

Copy link
Member

@dmarcos dmarcos Aug 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think functions is a very good name. All modules export functions. I would just name the file bind.js an do require('./bind');

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They'd be utility related to wrapping functions. I could imagine we'd add more function-related utilities in the future (e.g., debounce), and it'd be more organized and consistent to namespace them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed @ngokevin. We could add forEach (in some places we're doing [].forEach and others we're doing Array.prototype.forEach(NodeList), etc. I'm sure it will grow.

@codecov-io
Copy link

codecov-io commented Aug 12, 2016

Current coverage is 82.05% (diff: 93.33%)

Merging #1782 into master will increase coverage by 0.12%

@@             master      #1782   diff @@
==========================================
  Files           100        101     +1   
  Lines          3548       3573    +25   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           2907       2932    +25   
  Misses          641        641          
  Partials          0          0          

Powered by Codecov. Last update fb09d80...d091397

var registerComponent = require('../core/component').registerComponent;
var THREE = require('../lib/three');
var utils = require('../utils/');
var bind = utils.function.bind;
Copy link
Member

@dmarcos dmarcos Aug 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that the function namespace does not convey anything. Just call it utils.bind

Copy link
Member

@ngokevin ngokevin Aug 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It conveys function binding. What would utils.bind bind?

I'd like it for organization and consistency above anything else though.

Copy link
Member

@ngokevin ngokevin Aug 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think by itself it useful yeah. But I'd just like to be flexible in case we add some of http://underscorejs.org/#functions in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we add other functions in the future we can add the namespace. Let's keep it simple for now and not anticipate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could, but I don't understand why we wouldn't want to avoid a potential breaking change for the sake of a typing a few extra characters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

function resonates with you because you're familiarized with underscore. Without that context is meaningless.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may or may not, but I think it's smart to prepare for the possible scenarios. If we don't ever add more functions, then it might look cluttered (subjectively, I think it's organized). If we do and we end up namespacing it later, we have to call a breaking change and components using the function (possibly third-party) have to be migrated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't assume what resonates with me. It makes sense to me because the function utilities wrap functions, and there are various use cases of wrapping functions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you code trying to anticipate everything you will have super abstract unmaintainable code with optimizations that are there for no reason. Let's just add a bind file and generalize, create a namespace when there's a need.

Copy link
Member

@dmarcos dmarcos Aug 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I side note. We should not make those functions part of the public API to avoid the liability and have smaller API surface

@darkwing
Copy link
Contributor Author

Test added.

return this.propName;
}
};
assert.equal(obj.getProp(), bind(obj.getProp, obj)());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be useful to have a test that binds to a different obj with different value?

@darkwing darkwing force-pushed the 1762-bind branch 2 times, most recently from 67513f5 to d5e8831 Compare August 12, 2016 21:57
/**
* Faster version of Function.prototype.bind
*/
module.exports = function bind (fn, ctx/* , arg1, arg2 */) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function got more complicated because it doesn't accommodate for passing more arguments to bind, i.e. bind(fn, context, VALUE1, VALUE2). So I had to update it. :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the extra VALUE1 in light.js

Copy link
Member

@ngokevin ngokevin Aug 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good to have.

We can document this in the docstring

* @param {Function} fn - Function to wrap.
* @param {Object} ctx - What to bind as context.
* @param {...*} arguments - Arguments to pass through.

@darkwing
Copy link
Contributor Author

Updates made!

@ngokevin ngokevin merged commit f9c64ee into aframevr:master Aug 20, 2016
@cvan cvan removed the needs review label Aug 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants