Some questions about Private Name Objects

Matthew Robb matthewwrobb at gmail.com
Mon Aug 27 12:34:26 PDT 2012


In the end I am not looking for reads well, I am looking for minimal
semantic difference that can ideally work as a target for compiling to es3.
I am PREFERRING to not have functions as ownProperties. I can't use hard
binding because if the function is assigned to some place else it should no
longer be given access to the private name's it would have had as an
instance method/property (I'm assuming this actually).

I have done a little more playing around and am currently right about here:

class myClass {
    private test;
    constructor() {
        this[test] = 0;
    }
    getTest() this[test];
    doNothing(){}
}

COMPILES TO:

var myClass = (function(){

    var __myClass = function __myClass(__privates, __this) {

        // All class methods using private names would be defined here
        this.getTest = function() {

            // All appearances of this[test] would be replaced by the below
ternary operation
            return (this === __this ? __privates : this).test;
        }

        return (__this && (__this.__proto__ = this)) ? __privates : this;
    }

    var myClass = __myClass.prototype.constructor = function myClass() {
        var __privates = new __myClass({}, this);
        // Constructor body
        __privates.test = 0;
    }

     myClass.prototype = __myClass.prototype = new __myClass()

     myClass.prototype.doNothing = function(){}

    return myClass;

})();


On Mon, Aug 27, 2012 at 3:17 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 27/08/2012 19:54, Matthew Robb a écrit :
>
> I know this has some serious ugly to it but in the spirit of knowing what
> COULD potentially create the expected behavior, would this not do the trick?
>
>  var myClass = (function(){
>
>         function myClass(){
>             var __priv = Object.create(this);
>             var __this = __priv.__this = this;
>
>              this.getTest = function(){
>
> If you're willing to have functions as own properties in each instance,
> you need the method on the prototype any longer.
> If JS engines do their job properly, they will store the function body
> once and just create new function objects for each instance (which you do
> anyway, so it has no extra cost)
>
>
>                 return myClass.prototype.getTest.apply((this
> ===__this)?__priv:this, arguments);
>             }
>
>              __priv.test = 0;
>         }
>
>         myClass.prototype.getTest = function() {
>           var __this = this.__this || this, __private = this;
>            return __private.test;
>        }
>
>         return myClass;
>     })();
>
>
> Version with having a function on each instance:
>
>     function myClass(){
>         var test = 0;
>
>         this.getTest = function(){
>             return test;
>         };
>     }
>
> No underscore ;-)
>
> Through the different messages we've shared, you've covered the different
> ways to do encapsulation and code sharing and the conclusion is that either
> you need to add a function to each object (which yield a linear cost for no
> reason) or your abstaction leaks if you want to prototype function to
> access per-object data. A last alternative is to associate private data via
> a WeakMap (it can be shimmed in ES5 with the same garbage collection
> properties and with good performances) that inherited functions all have
> access to. It works, but it's burdensome and doesn't read as well as object
> properties.
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120827/92c55db5/attachment-0001.html>


More information about the es-discuss mailing list