Redefining structure accessors (summary)
Let's see if I can summarize the discussion. Attempts to redefine structure accessors should be a cerror. If you continue, then the structure is undefined (mostly) and the function is created. This seems better than the current behavior of just warning you about it and undefining the structure anyway. (compile accessor new-def) should also be a cerror. (setf (fdefinition accessor) new-def) shouldn't do anything special. The structure printer and inspector should be modified to use %instance-ref so that we can still print and inspect structures even if the accessor has been redefined. How does that sound? Ray
* Raymond Toy [2010-03-16 14:37+0100] writes:
Let's see if I can summarize the discussion.
Attempts to redefine structure accessors should be a cerror. If you continue, then the structure is undefined (mostly) and the function is created. This seems better than the current behavior of just warning you about it and undefining the structure anyway.
(compile accessor new-def) should also be a cerror.
(setf (fdefinition accessor) new-def) shouldn't do anything special.
The structure printer and inspector should be modified to use %instance-ref so that we can still print and inspect structures even if the accessor has been redefined.
How does that sound?
Fine with me. Helmut
On 3/16/10 10:09 AM, Helmut Eller wrote:
* Raymond Toy [2010-03-16 14:37+0100] writes:
Let's see if I can summarize the discussion.
Attempts to redefine structure accessors should be a cerror. If you continue, then the structure is undefined (mostly) and the function is created. This seems better than the current behavior of just warning you about it and undefining the structure anyway.
(compile accessor new-def) should also be a cerror.
(setf (fdefinition accessor) new-def) shouldn't do anything special.
The structure printer and inspector should be modified to use %instance-ref so that we can still print and inspect structures even if the accessor has been redefined.
How does that sound?
Fine with me.
Actually, there's one other alternative. When the accessor is redefined, we can silently (or noisily) replace the dsd-accessor function with nil. Then we don't get the strange behavior of our redefined function being used to access the slot. This also means we can't actually access the slot ourselves either because we'll try to get the fdefinition of nil. But the structure and everything else remains defined. (I have not tried that out yet.) I also notice that you can redefine the structure predicate without warning. Perhaps we should warn about this too. Ray
* Raymond Toy [2010-03-16 21:48+0100] writes:
Actually, there's one other alternative. When the accessor is redefined, we can silently (or noisily) replace the dsd-accessor function with nil. Then we don't get the strange behavior of our redefined function being used to access the slot. This also means we can't actually access the slot ourselves either because we'll try to get the fdefinition of nil. But the structure and everything else remains defined.
(I have not tried that out yet.)
If it works, good.
I also notice that you can redefine the structure predicate without warning. Perhaps we should warn about this too.
Possibly. At least typep is smart enough not to call the predicate name and still works if the predicate was redefined. Helmut
On 3/16/10 6:06 PM, Helmut Eller wrote:
* Raymond Toy [2010-03-16 21:48+0100] writes:
Actually, there's one other alternative. When the accessor is redefined, we can silently (or noisily) replace the dsd-accessor function with nil. Then we don't get the strange behavior of our redefined function being used to access the slot. This also means we can't actually access the slot ourselves either because we'll try to get the fdefinition of nil. But the structure and everything else remains defined.
(I have not tried that out yet.)
If it works, good.
Seems to work. But perhaps this is overly complex. Maybe we should just give up. We can signal a continuable error and if the user really wants to redefine the accessor, let him. It's up to him to make sure it's still usable as an accessor. If not, that's his problem; we warned him. :-) Ray
* Raymond Toy [2010-03-17 04:57+0100] writes:
On 3/16/10 6:06 PM, Helmut Eller wrote:
* Raymond Toy [2010-03-16 21:48+0100] writes:
Actually, there's one other alternative. When the accessor is redefined, we can silently (or noisily) replace the dsd-accessor function with nil. Then we don't get the strange behavior of our redefined function being used to access the slot. This also means we can't actually access the slot ourselves either because we'll try to get the fdefinition of nil. But the structure and everything else remains defined.
(I have not tried that out yet.)
If it works, good.
Seems to work. But perhaps this is overly complex. Maybe we should just give up. We can signal a continuable error and if the user really wants to redefine the accessor, let him. It's up to him to make sure it's still usable as an accessor. If not, that's his problem; we warned him. :-)
Yes, right. There might also be a problem with PCL which seems to create mirror classes (in a too hairy to understand fashion) and may or may not keep it's own copy of dsd-accessor. Either way structure-slotd-reader-function in pcl/low.lisp looks suspicious. Helmut
On 3/17/10 5:27 AM, Helmut Eller wrote:
* Raymond Toy [2010-03-17 04:57+0100] writes:
On 3/16/10 6:06 PM, Helmut Eller wrote:
* Raymond Toy [2010-03-16 21:48+0100] writes:
Actually, there's one other alternative. When the accessor is redefined, we can silently (or noisily) replace the dsd-accessor function with nil. Then we don't get the strange behavior of our redefined function being used to access the slot. This also means we can't actually access the slot ourselves either because we'll try to get the fdefinition of nil. But the structure and everything else remains defined.
(I have not tried that out yet.)
If it works, good.
Seems to work. But perhaps this is overly complex. Maybe we should just give up. We can signal a continuable error and if the user really wants to redefine the accessor, let him. It's up to him to make sure it's still usable as an accessor. If not, that's his problem; we warned him. :-)
Yes, right. There might also be a problem with PCL which seems to create mirror classes (in a too hairy to understand fashion) and may or may not keep it's own copy of dsd-accessor. Either way structure-slotd-reader-function in pcl/low.lisp looks suspicious.
Good point. I've checked in the changes. We just signal a cerror. If the user continues, then it's up to him to make sure that the redefinition is compatible. This check is done for defun and compile. No check is done for (setf fdefinition). Ray
On 3/16/10 6:06 PM, Helmut Eller wrote:
* Raymond Toy [2010-03-16 21:48+0100] writes:
I also notice that you can redefine the structure predicate without warning. Perhaps we should warn about this too.
Possibly. At least typep is smart enough not to call the predicate name and still works if the predicate was redefined.
The compiler doesn't know the names of the predicate function or the copier function either, so we can't currently check for that. We'd need to add that to the info database. Shouldn't be hard, but I don't feel like doing that right now. Ray
participants (2)
-
Helmut Eller -
Raymond Toy