Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inheritance improvement for editors #516

Merged
merged 7 commits into from
Mar 31, 2013
Merged

Conversation

tomalec
Copy link
Contributor

@tomalec tomalec commented Mar 22, 2013

Hi,

I made some improvements for HandsontableTextEditorClass, HandsontableAutocompleteEditorClass, and HandsontableDateEditorClass:

  1. To keep code clean and safe HandsontableDateEditorClass.prototype.constructor is now HandsontableDateEditorClass instead of HandsontableTextEditorClass (same for HandsontableAutocompleteEditorClass)
  2. HandsontableTextEditorClass is not triggered while setting inheritance, so if(instance) is no longer needed in constructor.
  3. Calling super methods seems to be much faster when using .apply, instead of adding Child.prototype._method = Parent.prototype.method; and calling it by this._method. Moreover it makes interface much cleaner.
    http://jsperf.com/declaration-apply-vs-prototype-reference-vs-super
    http://jsperf.com/instance-apply-vs-prototype-reference-vs-super/2

@warpech
Copy link
Member

warpech commented Mar 31, 2013

I am merging this with a change from apply to call, which I find more understandable and also faster: http://jsperf.com/calling-function-vs-apply-with-arguments

@tomalec
Copy link
Contributor Author

tomalec commented Mar 31, 2013

But note that if you are going to call method from prototype of different object (e.g. Parent) you will loos this context, which is vital in case of inheritance, isn't it? So in my opinion more applicable \test would look like this:
http://jsperf.com/inherited-function-call-vs-apply

Moreover I think in case of HT it would be a good idea to separate function definition and function calls. As calls happens far more often.

@warpech
Copy link
Member

warpech commented Mar 31, 2013

You are right, my link was wrong. Anyway .call has also a benefit that it uses the modified value of a variable if I happen to modify it, like in this hypothetical example:

HandsontableHandsontableEditorClass.prototype.finishEditing = function (isCancelled, ctrlDown) {
  if (Handsontable.helper.isDescendant(this.instance.rootElement[0], document.activeElement)) {
    isCancelled = true;
  }
  HandsontableTextEditorClass.prototype.finishEditing.call(this, isCancelled, ctrlDown);
};

What do you mean by separation of function definition and function calls?

@warpech warpech merged commit dc23670 into handsontable:master Mar 31, 2013
@tomalec
Copy link
Contributor Author

tomalec commented Apr 6, 2013

Correct me if I'm wrong, but .call and .apply behave same when modifying arguments: http://jsfiddle.net/tomalec/6kjE7/3/

So IE performance seems to be the only reason.

Here is what i mean by separation function definitions http://jsperf.com/declaration-apply-vs-prototype-reference-vs-super/2 and calls http://jsperf.com/inherited-function-call-vs-apply

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants