Re: Access protection

[kanderso@DINO.BBN.COM]

  Redistributed: commonloops.pa
  Date: Thu, 15 Mar 90 08:47 CST
  From: Nat Ballou <ballou@ernest.aca.mcc.com>
  Subject: Access protection
  To: commonloops.pa@xerox.com
  Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759
  Phone: (512) 338-3376
  
I did not get these messages in order, so i'll respond to them
individually.

  Another possible advantage of C++ over CLOS is the
  private/public/protected mechanism.  Roughly speaking, a public
  method or slot can be invoked on a class instance by anyone.  A
  private method or slot can be invoked only by the direct methods of
  a class, and a protected method or slot can be invoked by a direct
  or indirect method (i.e., a method on a subclass) of a class.

Yes, at first i worried that CLOS did not enforce encapsulation
issues.  Now i don't worry about it so much.  I worry about
encapsulation, i just don't worry about enforcing it.  During
debugging, it is useful to be able to have access to an objects
private parts temporarily.  For example, supose you were stuck at some
point and knew, you needed to some private behavior X.  You'd then
have to make it public, before you could continue to debug.  By the
time you were done debugging, you might have to make a lot of things
temporarily public, and you might forget to make them private later,
and over time, users might rely on it being public...  This problem
gets amplified in big programming projects.  Programmers may agree
amongst themselves to make everything public to speed development,
without telling management...  CLOS encourages encapsulation, without
enforcing it.

Also, if you accepted the public/private duality, since CLOS has a
meta level, you also have to decide what metapublic and metaprivate
mean. 
  
  If we were to use Common Lisp packages for this purpose, there seems
  to be a few inconveniences.  First, suppose that I have a method and
  a setf method defined for the symbol FOO.  Suppose I want the method
  FOO to be public, but not the setf method FOO.  How can I do this
  without renaming my setf method?  Will the method specification
  (SETF FOO) have a package of its own in ANSI CL?

Put FOO in a public package, and (SETF FOO) in a private package. 
  
  The Common Lisp export/import mechanism may be able to provide
  functionality similar to the public/private mechanism in C++.
  However, it is unclear how to best implement the protected
  mechanism.  Things become even more difficult when one allows a
  subclass to change an inherited method or slot from public to
  private, as in C++.

Aternatively, you could probably use the metaclass protocol to
identify private violations.

k