Remove dev-only comments for updating thisArg

v4.4.3

4.4.3

refactoring Scope.prototype.hasKey to avoid using getPathsForKey

#173

Not removing scope.getPathsForKey in production

scope.getPathsForKey should only be used in development-mode, but there is at least one thing using it in production, so leaving it in for now. Will remove it once this has been fixed.

#172.

adding support for scope.vm and scope.top

#170

read returns parentHasKey data

var VM = DefineMap.extend({
  foo: "string"
});
var vm = new VM();
var scope = new Scope(vm);
scope.read("foo").parentHasKey; // -> true

This also makes it so that getPathsForKey will return back paths where the key returns a function.

not including notContext scopes in correct paths

#167

implementing can.hasKey Symbol on Scope.prototype

#163

Preventing errors in getPathsForKey when a context is not an object

#162

Better alternatives for scope.root

This adds two new scope properties:

• scope.vm - the first context that is a viewModel
• scope.top - the "top" context that is a viewModel

This also deprecates scope.root in favor of these more explicit properties.

This release also adds scope.getPathsForKey, which will be documented in a future release.

#161

Always show ScopeKeyData slow-path dependency graphs

This shows the "slow-path" graph all the time now for ScopeKeyData.

Here is what it looks like for regular properties (like name):

and nested dependencies (like person.name):