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

[BUGFIX release] fix the leaks #11832

Merged
merged 2 commits into from
Jul 21, 2015
Merged

Conversation

stefanpenner
Copy link
Member

water-damage-carpet-cleaning

@pixelhandler
Copy link
Contributor

@stefanpenner oh ok I didn't see any api for the private export _loaded so it seemed safe to delete the reference. What are those unfortunate side effects? I looked here https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete and here http://perfectionkills.com/understanding-delete/#ie_bugs I assume by unfortunate side-effects you mean IE.

Seems fine to assign undefined was just curious if Ember intentionally avoids the delete operator.

@@ -10,6 +10,7 @@ import 'ember-runtime/system/native_array'; // make sure Ember.A is setup.

var loadHooks = Ember.ENV.EMBER_LOAD_HOOKS || {};
var loaded = {};
export var _loaded = loaded;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this really private? It's exported. I know JS doesn't really have 'protected' but am wondering if you can add a doc block on the export for _loaded What is this? private / public etc.

Copy link
Member Author

Choose a reason for hiding this comment

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

undocumented is private and our modules are not exposed by any public means, once they are a different facade will be exposed that enables 100% public only public API.

@stefanpenner
Copy link
Member Author

What are those unfortunate side effects?

It changes the shape of the object, which causes the object from which the property was deleted it to go into slow mode. In this example, it doesn't matter, but both are functionality equivalent. If this is a problem i can change it.

@@ -37,7 +37,7 @@ import LegacyEachView from 'ember-views/views/legacy_each_view';
import LinkToComponent from 'ember-routing-views/views/link';
import RoutingService from 'ember-routing/services/routing';
import ContainerDebugAdapter from 'ember-extension-support/container_debug_adapter';

import { _loaded } from 'ember-runtime/system/lazy_load';
Copy link
Contributor

Choose a reason for hiding this comment

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

at first glance this does seem strange import { _blah } I looked at the definition and don't know whether this is private just am assuming that the underscore prefix means private.

Copy link
Member Author

Choose a reason for hiding this comment

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

all modules are currently private, as they are not exposed.

@stefanpenner stefanpenner force-pushed the dont-leak-in-onload branch 2 times, most recently from ffa2423 to a6947ba Compare July 20, 2015 23:25
@stefanpenner stefanpenner changed the title [BUGFIX release] don’t leak application instances in onLoad _loaded [BUGFIX release] fix the leaks Jul 20, 2015
@stefanpenner
Copy link
Member Author

finally our friend saucelabs is happy, kept timing out..

@stefanpenner
Copy link
Member Author

@rwjblue r?

@rwjblue
Copy link
Member

rwjblue commented Jul 21, 2015

👍

rwjblue added a commit that referenced this pull request Jul 21, 2015
@rwjblue rwjblue merged commit acecb9f into emberjs:master Jul 21, 2015
@rwjblue rwjblue deleted the dont-leak-in-onload branch July 21, 2015 03:51
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.

3 participants