Warp wrote:
> "Like the OO systems in most dynamic languages, CLOS does not enforce
> encapsulation. Any data member (or slot) can be accessed using the
> slot-value function or via (optionally auto-generated) accessor
> methods."

BTW, this is only true in CLOS. If you actually implement OO using closures, 
this isn't the case.

As a sort of C++ equivalent, consider C++'s upcoming lambda expressions. If 
you write something like

{ int x, y;
   x = 3; y = 4;
   std::function pdq = [x,y](z) {return x+y+z;}
   x = 8; y = 9;
   // What here could you write to get the "4" that's in y inside pdq?
}

(Assuming I'm close on the syntax, and I think I'm saying pass x and y by 
value to the pdq lambda thingie.)

Building OO via closures is like that, except the x and y serve the purpose 
of instance variables. (C++ doesn't have actual closures, so the analogy is 
flawed here, of course, but if you don't see how closures can make objects, 
that should clarify it.)

If you could pass x and y by reference, declared several std::functions that 
used them by reference, and then return collection of those functions 
without actually losing the stack frame those referneces referred to, you'd 
have objects-on-closures, with no access to internal instance variables.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message