From 55f47a3c5a1af6dcdb9656201eb4b2750bb34723 Mon Sep 17 00:00:00 2001 From: Mike Gerwitz Date: Sat, 4 Nov 2017 00:34:00 -0400 Subject: [PATCH] Correct Trait#__inst in ES3 environments The previous commit's test case failed in ES3 environments. I'd amend that commit, but Savannah refuses force pushes, and I can't work around that on `master'. * lib/Trait.js (tctor): Assign `__inst' to the public visibility object rather than `vis'. --- lib/Trait.js | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lib/Trait.js b/lib/Trait.js index dc0758e..878cdfe 100644 --- a/lib/Trait.js +++ b/lib/Trait.js @@ -947,10 +947,16 @@ function tctor( tc, base, privsym ) // (but not private); in return, we will use its own protected // visibility object to gain access to its protected members...quite // the intimate relationship - this[ f ] = C( base, this[ privsym ].vis )[ privsym ].vis; + var tinst = C( base, this[ privsym ].vis ); + this[ f ] = tinst[ privsym ].vis; // TODO: this should use util.defineSecureProp - this[ f ].__inst = this[ privsym ].inst; + // we set __inst on the trait object itself (public visibility + // object, which is okay, since the trait is encapsulated anyway) + // because otherwise, in the case of an ES3 fallback, `vis' will be + // affected by __inst defined on `base', leading to a fight over + // ownership that I spent too much time trying to figure out + tinst.__inst = this[ privsym ].inst; // rebind trait's supertype context (if any) to our own, causing us // to share state