|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |