Data abstraction is clearly an important technique for creating
maintainable code. That is creating a chunk of code which has a well
defined set of functions and variables that can be included in with
another chunk of code. The interface is defined and that, at least
conceptually, is all the using code gets access to. In particular,
nothing else in its name space is trampled on, and the details of the
implementation of the original code can be changed with no change in
the functionality of the using code.
It appears to be the case that the only thing approaching data hiding
that is available in Common Lisp is packages. This seems a rather
course level for such a useful concept especially when I compared to
C++ which provides data hiding for every class. I only say
approaching because you still can get your fingers into the package
with '::'.
First, I want to know if packages really are the only type of data
hiding in Common Lisp. Second, I'd like to solicit comments, rants,
dogma, flames, suggestions etc on this subject. In particular, why
did X3J13 only provide this one heavy handed technique and do people
generally consider this a blessing or a curse.
Nathan Wilson
······@cse.ucsc.edu
In article <············@darkstar.UCSC.EDU>, ······@cse.ucsc.edu (Nathan J. Wilson) writes:
|> Data abstraction is clearly an important technique for creating
|> maintainable code. That is creating a chunk of code which has a well
|> defined set of functions and variables that can be included in with
|> another chunk of code. [...]
|> It appears to be the case that the only thing approaching data hiding
|> that is available in Common Lisp is packages.
There are, in fact, a number of mechanisms for data
abstraction in CommonLisp:
* defining accessors etc. as functions (SCIP style)
* using DEFSTRUCT
* using DEFCLASS
Objects defined with DEFSTRUCT and DEFCLASS are already "pretty opaque",
meaning that you have to go through some gyrations to actually get
at bits and pieces of the underlying representation without going through
the defined interface.
The backdoors that there are are there so that you can write code like
debuggers, inspectors, and OODBs without having to rely on implementation-
dependent mechanisms. If you don't want to violate data abstraction,
simply don't use those functions.
The situation in C++ (which you mention later) isn't much different.
For practical purposes, any program can get at the representation of an
object by pointer casting, and packages that need to (OODBs, debuggers,
inspectors, etc.) get the necessary information about an object by
looking at the source code (and they do!). That violates opaqueness
just as much, but in addition, is less convenient and less safe.
For what it's worth, CL structures probably aren't accessible enough;
for example, there is no portable way to access a structure slot
by name. Another type that is nearly completely opaque in CL is
the closure (SCIP gives lots of examples of how to use closures
for data hiding). I think most CL programmers view these as shortcomings
of the language definition that makes some perfectly reasonable code
difficult to write portably.
|> It appears to be the case that the only thing approaching data hiding
|> that is available in Common Lisp is packages. This seems a rather
|> course level for such a useful concept especially when I compared to
|> C++ which provides data hiding for every class. I only say
|> approaching because you still can get your fingers into the package
|> with '::'.
Packages really serve a somewhat different function from other
facilities for abstraction and encapsulation: they are primarily
there to avoid name conflicts. C++ lacks an equivalent construct,
but it may eventually be added through the C++ namespace proposal.
If you want to make a symbol completely inaccessible in CL at this
level, you can do so by uninterning it. I suspect most programmers
would find such a draconian approach too cumbersome; "::" is enough
of a warning sign to most CL programmers, and it is helpful for
debugging.
All of this isn't to say that CL's facilities for abstraction
and modularization are perfect. I'd prefer if there was a clearer
distinction being made between constructs that violate encapsulation
and those that don't (preferably, the distinction should be made in
the choice of name or package). Also, resolving name conflicts among
package names is somewhat tricky (the CL module system is hardly unique
in this respect; a hierarchical approach might solve this problem).
Thomas.
In article <············@darkstar.UCSC.EDU> ······@cse.ucsc.edu (Nathan J. Wilson) writes:
>Data abstraction is clearly an important technique for creating
>maintainable code.
[much deleted]
>Nathan Wilson
Could you tell me how you know this? I'm not denying the statement,
but I would like to know of any studies that have been done that show
that data abstraction is in fact a means to increasing the
maintainability of the code.
Barry Smith
In article <············@darkstar.UCSC.EDU> ······@cse.ucsc.edu (Nathan J. Wilson) writes:
It appears to be the case that the only thing approaching data hiding
that is available in Common Lisp is packages. This seems a rather
course level for such a useful concept especially when I compared to
C++ which provides data hiding for every class. I only say
approaching because you still can get your fingers into the package
with '::'.
First, I want to know if packages really are the only type of data
hiding in Common Lisp. Second, I'd like to solicit comments, rants,
dogma, flames, suggestions etc on this subject. In particular, why
did X3J13 only provide this one heavy handed technique and do people
generally consider this a blessing or a curse.
Other, more modern Lisps have done a better job of providing
encapsulation. In particular, EuLisp and Le-Lisp both have real
module systems which allow you to export only a subset of your
module's definitions, and are based on bindings rather than symbols.
Le-Lisp also has a complementary package system used for namespace
separation.
I believe Dylan is planning on incorporating a module system in the
future, but I haven't heard anything about it for almost a year.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France