Re: CLOS and C++

From: Peter Seibel (peter_at_javamonkey.com)
Date: 11/25/03 

Date: Tue, 25 Nov 2003 07:56:39 GMT

"Geoffrey Summerhayes" <sRuEmMrOnVoEt@hotmail.com> writes:

> "Steven E. Harris" <seharris@raytheon.com> wrote in message
> news:q671xrx1mwe.fsf@raytheon.com...
> > heliosc@mindspring.com (Rayiner Hashem) writes:
> >
> > > I think the reasoning is that in Lisp/CLOS encapsulation is
> > > orthogonal to the class mechanism. If you want to prevent a client
> > > from changing a class's internal members, put it in a seperate
> > > package and don't export the setter methods for that member.
> >
> > Ah, I had not thought of that. At the time I was reading the
> > aforementioned Norvig book, I didn't understand CL packages, but
> > thinking about it today I can see your point.
> >
> > > You can get the equivilent of a C++ class with public interfaces and
> > > private members by making a seperate package for the class, and only
> > > exporting the public functions.
> >
> > Unfortunately, I haven't seen this advice elsewhere. A person coming
> > from a background in C++ or Java would want to hear advice like this
> > for reassurance that access control can be layered over CLOS, whether
> > or not it's idiomatic to do so.
>
> I think this will be a fairly easy sell, but I'm going to have a tougher
> time with the lack of destructors. My basic line on this will be:
>
> 1-reclamation of memory is handled automatically by the GC
> 2-reclamation of other system resources is problematic in a GC'd
> language and best handled with other methods
>
> Any additional thoughts?

Constructs like WITH-OPEN-FILE also handle many of the cases that
destructors are used for--to guarantee that certain resources such as
file handles are released before the exit of a block. And since they
are syntactically obvious they are arguably a much better way to
express what is really going on.

Also, as part of 2 you can point out that Java has no destructors. Of
course you might need to be prepared to field questions about the Lisp
equivalent of finalization (a bad idea as anything more than a backup
and actually implemented in a pretty busted way in Java) and (if your
audience is full of real Java weenies) the Reference classes which are
the new version of finalization that actually work. I'm not sure what
the Lispy equivalents are; certainly they are implementation
dependent.

-Peter 

-- 
Peter Seibel                                      peter@javamonkey.com
         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Relevant Pages

  • Re: finalize() not guaranteed to be called -- ever
    ... >> problem is that objects in variables have value semantics and not ... is also the justification for not including this possibility in Java. ... Just adding destructors ... You suggest that the JVM can just guarantee that finalize() is called, ...
    (comp.lang.java.programmer)
  • Re: Thread-question
    ... > allocation/deallocation under the control of the programmer has too many ... I think I'm coming more from the point of view that Java finalization is ... limited resources, and especially unsuited to managing resources whose ...
    (comp.lang.java.gui)
  • Re: Thread-question
    ... > allocation/deallocation under the control of the programmer has too many ... I think I'm coming more from the point of view that Java finalization is ... limited resources, and especially unsuited to managing resources whose ...
    (comp.lang.java.programmer)
  • Re: Thread-question
    ... > allocation/deallocation under the control of the programmer has too many ... I think I'm coming more from the point of view that Java finalization is ... limited resources, and especially unsuited to managing resources whose ...
    (comp.lang.java.help)
  • Re: Class destructors
    ... The explanation I remember is destructors are generally used to free ... That's one of the things that bothers me about Java. ... the theory and science of your algorithms. ... reference to them have a one-to-one relationship destructors make sense. ...
    (comp.lang.java)
Loading