Subject: Re: multiple copies of a CLOS object? From: Erik Naggum <erik@naggum.net> Date: Fri, 27 Jul 2001 21:04:08 GMT Newsgroups: comp.lang.lisp Message-ID: <3205256646517069@naggum.net> * Amanda Stent <stent@cs.rochester.edu> > Is there a CLOS function for copying a CLOS object so that you end up > with two clones that are thereafter independent? No. There is no way to define "copy" such that this can be done without serious intervention from the creator of the class. E.g., if you have a symbol as the value of a slot, do you want to copy the symbol, and if you copy the symbol, do you want to copy the package? If you do copy the package, do you want to copy _all_ its symbols? Obviously, this leads to a copy of the entire Lisp world in no time (in practice it will much more time). You are better off with the Unix system call "fork". This is not normally what people think of when they want a copy of an object, however. If you believe that a shallow copy is the right default choice in sharp contrast to the very deep copy described above, consider an object that points to itself with one of its slots. A shallow copy would not make the "clones" independent at all, they would be like Siamese twins, and you would likely wreak havoc if you believed they _were_ independent. In the Common Lisp world, we do not generally believe in functions that work "most of the time", but look for the border conditions that make it necessary to point out when it works and when it does not. A general "copy constructor" is not well-defined enough to make this possible. Besides, there is so much going on in CLOS objects that even if you succeed in making a copy, you may have broken many significant other things that depended on object identity in ways the object may not know about. See also the desire to compare two objects for anything other than object identity. Those who say it can be done are simply wrong, because the information necessary to accomplish this seemingly simple task is not specified by the language. It is in the _intent_ of the programmer, not the _expression_ of that intent. Until we find a way to write down the intent directly, we can only deal with expressions of intent in our programming languages. In other words, the PhD-level answer is "create a language such that it can automatically construct a copy constructor that always does the right thing". It is simpler to write the code for your own copying function. #:Erik -- There is nothing in this message that under normal circumstances should cause Barry Margolin to announce his moral superiority over others, but one never knows how he needs to behave to maintain his belief in it.