[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Access protection
- To: commonloops.pa@Xerox.COM
- Subject: Re: Access protection
- From: Nat Ballou <ballou@ERNEST.ACA.MCC.COM>
- Date: Thu, 15 Mar 90 10:53 CST
- Phone: (512) 338-3376
- Postal-address: 3500 West Balcones Ctr. Dr., Austin, TX 78759
- Redistributed: commonloops.pa
It's important to separate two entirely different issues. There are two
features to C++. The first feature is some support for object oriented
programming. The second feature is basically data abstraction or data
hiding. OOP does not automatically include the second feature.
I'm simply trying to match features. I'm not trying to say whether such
things are part of OOP or not (i.e., from your point of view, I am simply
trying to do OOP with a little data abstraction and/or data hiding :-).
In particular the LISP environment is one where people often hack around and
nearly every manipulation is possible. This said there is an answer to
the (setf foo) problem. Instead of declaring the slot with
:accessor foo you declare it with :reader foo and no setf function is
generated. I'm not sure what, if anything, will happen in a WITH-SLOTS
form if you use SETF.
I realize that a hacker can do anthing s/he wants. I also realize that if a
programmer does not use '::' syntax, and makes use of only the exported
functionality of a package, the same programmer can achieve an environment
similar to C++ (with public/private/protected methods and slots). In doing
so, some nice features of CLOS (i.e., SETF methods) cannot be used if the same
programmer wants to present a consistent interface to users.
For those lisp hackers who put everything (AND the kitchen sink) in the same
package ... never mind :-)