On Monday, August 27, 2012 at 3:34 PM, Matthew Robb wrote:
> 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;
>
>
>
Just a heads up: max-min classes do not include support for declaring data
properties or private variables in the class body.
On a broader note, we discussed renaming Name to Symbol, here:
https://mail.mozilla.org/pipermail/es-discuss/2012-August/024278.html
Rick
> 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 <[email protected]
> (mailto:[email protected])> 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
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
