> Hi Jonathan,
> I found in the documentation for concur that you are referring to
> Backbone-style inheritance as "infectious". I haven't come across this term
> anywhere else, except for in medical context. But then, I haven't really
> seen any other terms used to describe this fairly popular style of
> inheritance in JS. Just wondering, where does it originate from?
> Thanks,
> Konstantin
> On Tue, Oct 16, 2012 at 3:56 PM, Konstantin Kudryavtsev <
> konstantin.k...@gmail.com> wrote:
>> That helps. Thanks a lot!
>> KK
>> On Tue, Oct 16, 2012 at 2:51 PM, Jonathan Buchanan <
>> jonathan.bucha...@gmail.com> wrote:
>>> On 16 October 2012 11:31, Konstantin Kudryavtsev <
>>> konstantin.k...@gmail.com> wrote:
>>>> Dear JS Mentors,
>>>> Could you please help me understand the use of Surrogate class in
>>>> Backbone's extend function
>>>> https://github.com/documentcloud/backbone/blob/master/backbone.js#L1436 .
>>>> In particular, why do this: http://jsfiddle.net/z4jMc/ if you can do
>>>> that: http://jsfiddle.net/8J3SZ/2/ (less code in the second case).
>>>> Really appreciate your help!
>>>> Cheers,
>>>> Konstantin
>>> The "surrogate" form puts the parent constructor's prototype in the
>>> child constructor's prototype chain - this is the standard workaround for
>>> using the behaviour of the "new" keyword to put a particular object in a
>>> prototype chain to simulate inheritance, for compatibility where other
>>> means of manipulating prototype chains (Object.create and __proto__) may
>>> not be available.
>>> Given this setup::
>>> var Parent = extend.call(Object, {})
>>> var Child = extend.call(Parent, {})
>>> var c = new Child()
>>> ...the following is true for the surrogate version, but not for the
>>> _.extend() version::
>>> // Parent.prototype is in Child.prototype's prototype chain
>>> // Parent properties will be found by walking the prototype chain at
>>> lookup time
>>> Child.prototype.__proto__ === Parent.prototype
>>> Resulting differences for the surrogate version:
>>> * objects created with a "child" constructor will also be instanceof
>>> their "parent" constructor (and any other ancestor constructors)
>>> * since parent prototype properties are resolved when looked up, any
>>> changes made to the parent prototype will be accessible to child instances
>>> Try this with both implementations::
>>> var Parent = extend.call(Object, {})
>>> var Child = extend.call(Parent, {})
>>> var c = new Child()
>>> Parent.prototype.newThing = true
>>> console.log('c is ' +
>>> (c instanceof Parent ? '' : 'not ') +
>>> 'a Parent')
>>> console.log('Parent.prototype is ' +
>>> (Child.prototype.__proto__ === Parent.prototype ? '' :
>>> 'not ') +
>>> "in Child's prototype chain")
>>> console.log('Parent.prototype is ' +
>>> (c.__proto__.__proto__ === Parent.prototype ? '' : 'not
>>> ') +
>>> "in c's prototype chain")
>>> console.log('c ' +
>>> (typeof c.newThing == 'undefined' ? 'does not have' :
>>> 'has') +
>>> ' access to newThing')
>>> I also have an example of going from vanilla JS inheritance to this
>>> style of inheritance sugar here [1]
>>> Jonny.
>>> [1] https://github.com/insin/concur/blob/master/README.rst
>>> --
>>> To view archived discussions from the original JSMentors Mailman list:
>>> http://www.mail-archive.com/jsment...@jsmentors.com/
>>> To search via a non-Google archive, visit here:
>>> http://www.mail-archive.com/jsmentors@googlegroups.com/
>>> To unsubscribe from this group, send email to
>>> jsmentors+unsubscribe@googlegroups.com
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/jsment...@jsmentors.com/
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/jsmentors@googlegroups.com/
> To unsubscribe from this group, send email to
> jsmentors+unsubscribe@googlegroups.com
