Article View: comp.lang.clos
Article #245Re: Copying objects
From: Barry Margolin
Date: Tue, 27 Nov 1990 07:14
Date: Tue, 27 Nov 1990 07:14
41 lines
2656 bytes
2656 bytes
In article <1990Nov26.192413.23214@cs.columbia.edu> djk@cs.columbia.edu (David Kurlander) writes:
>Is there a way to copy an instance of an object? Something similar to
>the structure copiers generated for defstructs? I'd hate to have to
>define a specific method for each class.
No, there is no standard copying function, and this was intentionally
omitted. The same goes for equivalence functions (although we might have
given in and defined EQUALP for CLOS objects, I don't remember). The
appropriate behavior of a copying or equivalence function is generally
application-dependent. Should the copy be deep (copying the entire
structure, sharing pointers to leaves, a la copy-tree) or shallow (copying
only the top-level structure, like copy-list)? If deep, what types of
objects are leaves (for copy-tree it's simple -- anything but a cons is a
leaf). What do you get when you pass an instance of a subclass to a
superclass's copier (we almost got rid of DEFSTRUCT copiers while trying to
hash out this ambiguity)?
We already have four equivalence predicates (EQ, EQL, EQUAL, EQUALP), but
they don't do all the things people want (or sometimes expect). Many of us
in X3J13 believe that EQUAL was a big mistake in Lisp. Trees of conses
generally represent some higher-level data structure, and it would probably
have been better to force programmers to define higher-level comparison
functions for them; EQUAL is generally a lazy solution.
It's too late to fix EQUAL. But we didn't want to make the same mistake in
CLOS by adding a copier.
I did some design a couple of years ago on generic functions COPY-OBJECT
and EQUAL-OBJECT. They solve the above shallow/deep issue by taking
parameters that indicate how to recurse. In particular, there was a type
specifier parameter that indicated which types should be copied
recursively. Type-specific keyword arguments could be passed in, which
could be used to further parametrize the way individual types are copied
(for instance, :LIST T indicates that conses should be copied with
COPY-LIST rather than COPY-TREE).
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
Technical Details
Message-ID:
<1990Nov27.071408.16622@Think.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!barmarReferences:
<1990Nov26.192413.23214@cs.columbia.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.clos Subject: Re: Copying objects Message-ID: <1990Nov27.071408.16622@Think.COM> Date: 27 Nov 90 07:14:08 GMT References: <1990Nov26.192413.23214@cs.columbia.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 41