Fwiw the pattern of using iife's in js to call pseudo-methods without separately instantiating an object using "new" is so clean to me. I'm a huge fan of the revealing module pattern. Your pattern is interesting. One thing that drives me nuts is I've yet to find an es6 pattern that matches the revealing module pattern in terms of being self contained and simplistic. Module exports are wacky to me, having to create a new file for each "object" and exporting functions individually in order to namespace them. And static methods in a class dont have access to constructor properties. The revealing module pattern hit on all of this...And if I wanted to put a bunch of iife's in one file and make said functionality available globally - yet namespaced - I could. To me it's like we went backwards with these es6 imports...it's become more procedural. just a gripe.
Fwiw the pattern of using iife's in js to call pseudo-methods without separately instantiating an object using "new" is so clean to me. I'm a huge fan of the revealing module pattern. Your pattern is interesting. One thing that drives me nuts is I've yet to find an es6 pattern that matches the revealing module pattern in terms of being self contained and simplistic. Module exports are wacky to me, having to create a new file for each "object" and exporting functions individually in order to namespace them. And static methods in a class dont have access to constructor properties. The revealing module pattern hit on all of this...And if I wanted to put a bunch of iife's in one file and make said functionality available globally - yet namespaced - I could. To me it's like we went backwards with these es6 imports...it's become more procedural. just a gripe.
I agree with you, using the IIFE has a single execution context thus there is a single closure.
My point was that closure may exist without the need of using an IIFE.
Also, you are right: we both know how to use closure ;)