[General] Encapsulation in LK
Owen Densmore
owen at backspaces.net
Sun May 3 16:58:36 CEST 2009
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, at 1:49 PM, Daniel Ingalls wrote:
> 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
> _______________________________________________
> General mailing list
> General at livelykernel.sunlabs.com
> http://livelykernel.sunlabs.com/mailman/listinfo/general
More information about the lively-kernel
mailing list