From ed1110db0cb9ed5b76e182ae9235d192a18316a8 Mon Sep 17 00:00:00 2001 From: pansay Date: Sun, 17 Apr 2016 12:08:11 +0200 Subject: [PATCH 1/2] Update binding.md --- manuscript/markdown/Instances and Classes/binding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manuscript/markdown/Instances and Classes/binding.md b/manuscript/markdown/Instances and Classes/binding.md index 70284d9..3f7edfc 100644 --- a/manuscript/markdown/Instances and Classes/binding.md +++ b/manuscript/markdown/Instances and Classes/binding.md @@ -22,7 +22,7 @@ How would this help us in a practical way? Consider building an event-driven app someView.render() }); -This tells `someModel` that when it invoked a `change` event, it should call the anonymous function that in turn invoked `someView`'s `.render` method. Wouldn't it be simpler to simply write: +This tells `someModel` that when it invokes a `change` event, it should call the anonymous function that in turn invokes `someView`'s `.render` method. Wouldn't it be simpler to write: someModel.on('change', someView.render); From 70ad67b259dcba1f04685d907a87f6c270471599 Mon Sep 17 00:00:00 2001 From: pansay Date: Sun, 17 Apr 2016 12:14:35 +0200 Subject: [PATCH 2/2] Update binding.md --- manuscript/markdown/Instances and Classes/binding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manuscript/markdown/Instances and Classes/binding.md b/manuscript/markdown/Instances and Classes/binding.md index 3f7edfc..13a094d 100644 --- a/manuscript/markdown/Instances and Classes/binding.md +++ b/manuscript/markdown/Instances and Classes/binding.md @@ -76,7 +76,7 @@ This is a very popular pattern, so much so that many frameworks provide helper f There are two considerations to ponder. First, we may be converting an instance method into an object method. Specifically, we're creating an object method that is bound to the object. -Most of the time, the only change this makes is that it uses slightly more memory (we're creating an extra function for each bound method in each object). But if you are a little more dynamic and actually change methods in the prototype, your changes won't "override" the object methods that you created. You'd have to roll your own binding method that refers to the prototype's method dynamically or reorganize your code. +Most of the time, the only difference this makes is that it uses slightly more memory (we're creating an extra function for each bound method in each object). But if you are a little more dynamic and actually change methods in the prototype, your changes won't "override" the object methods that you created. You'd have to roll your own binding method that refers to the prototype's method dynamically or reorganize your code. This is one of the realities of "meta-programming." Each technique looks useful and interesting in isolation, but when multiple techniques are used together, they can have unpredictable results. It's not surprising, because most popular languages consider classes and methods to be fairly global, and they handle dynamic changes through side-effects. This is roughly equivalent to programming in 1970s-era BASIC by imperatively changing global variables.