[cmucl-imp] Re: Redefining structure accessors (summary)

[Raymond Toy]

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