[General] Encapsulation in LK

hi, it does not look like LK provides any language extension to help
with encapusulation, so all the properties of LK "classes" are public,
isn't it?

Hi Haowei -

Yes.  I have been pushing to augment our current "extends" construct  
with a message category name, so that the browser can give a bit more  
help in the case of major classes.  I believe this would be the place  
to add a public/private distinction as well.

It's true that without a type system it is harder to guarantee proper  
behavior, but in my view 90% of the value is in highlighting the  
public protocol so the system is more understandable, and authors are  
motivated to make it so.

The fact is that with our cool method-wrapping metasystem (that we use  
for profiling of various sorts) it would be easy (truly only a couple  
of lines of code!) to implement a test mode in which the system ran  
with dynamic checks for violation of private access.  This is not a  
guarantee of conformance, but  it would catch violations in any code  
that actually ran.  I think we'd be very happy with the result.

Thanks for your interest

        - Dan

I'm just getting my head around JS fine points, so this could be way  
off!  But I believe for private method/class variables, you'd use a  
closure during the object construction (new).

This closure would have "var" variables, in addition to the "this"  
variables.  These variables would only be visible to methods, and  
could not be retrieved directly via the dot notation.

Whew!

    -- Owen


On May 1, 2009,@1:49 PM, Daniel Ingalls wrote:

On Sun, May 3, 2009@7:58 AM, Owen Densmore <[hidden email]> wrote:
> I'm just getting my head around JS fine points, so this could be way
> off!

You have this exactly right. JavaScript has only one working
encapsulation mechanism. This pattern of using it for defining
encapsulated objects is due to Doug Crockford (cc'ed) and is known as
the "objects as closures" pattern.

> But I believe for private method/class variables, you'd use a
> closure during the object construction (new).
>
> This closure would have "var" variables, in addition to the "this"
> variables. ?These variables would only be visible to methods, and
> could not be retrieved directly via the dot notation.

Actually, in the objects as closure pattern, "this" and "new" are both
useless. ("new"@least is also harmless. Not so for "this".) For
example:

  function Point(x, y) {
    var magnitude = Math.sqrt(x*x + y*y);
    var self = {
      getX: function(){ return x; },
      getY: function(){ return y; },
      getSize: function(){ return magnitude; },
      toString: function() {
        return '<' + self.getX() + ',' + self.getY() + '>';
      }
    }

Such an object is just a record of methods, each of which is a closure
defined in the object's construction context. The captured lexical
variables from that construction context are the object's instance
variables (x, y, magnitude, self). As Dan will remember, this view of
objects hearkens back to some of the early thinking around
Smalltalk-72 and Actors (though Smalltalk-72 had dynamic scoping).
Further elaborations of this pattern (See the Cajita examples in
<http://google-caja.googlecode.com/files/caja-spec-2008-06-07.pdf>)
can accommodate inheritance, and, on Caja and the upcoming EcmaScript
5, can make these objects tamper proof (via freezing). The
objects-as-closure pattern will also be the basis for the class system
of EcmaScript Harmony (which is likely to become EcmaScript 6).

The problem with this pattern today is that is costs one allocation
per method per instance. In previous conversations with Lively Kernel
folks, this cost was felt to be a show stopper for use of this pattern
in LK. AFAIK, no other workable technique for encapsulation has yet
been discovered for JavaScript.

--
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM