[closer-devel] Re: Initargs of slot definitions: I miss COMPUTE-E-S-D-INITARGS

[Pascal Costanza]

On 25 Nov 2006, at 14:43, Ivan Boldyrev wrote:

> On 9668 day of my life Pascal Costanza wrote:
>> I think option 2 would be ok in general, and I wouldn't mind much
>> whether it adheres to any OOP principles or not.
>
> I do mind, because it clutters code with unnecessary details.

That's of course indeed a valid position to take.

>> The more important reason to be more specific here is that calls to
>> slot-xyz-using-class can be optimized away when the arguments are
>> all of standard metaclasses.  So I always try to use as few metaclass
>> specialization as possible here.
>
> Currently my slot-definitions keep information about their relations
> to other slots.  Perhaps, I should move this information from
> slot-level to class-level and use standard slot definitions.

Maybe this is not necessary. The possible impact on efficiency that I  
was talking about only occurs when you define methods on slot-xyz- 
using-class, like this:

(defmethod slot-value-using-class ((class my-class) object (slotd my- 
slot-definition))
   ...)

When a slot is a standard-slot-definition, and methods on slot-xyz- 
using-class don't apply, a CLOS implementation has a chance to  
optimize the overhead of calling slot-value-using-class away. If you  
don't specialize slot-xyz-using-class, this doesn't matter because  
there is no method that could interfere with efficiency concerns.

>> I have seen option 3 being used in example code, even example code
>> shown by Kiczales et al. In my opinion, the CLOS MOP specification is
>> overly strict here - maybe a copy&paste issue in the spec, I don't
>> know. Anyway, that's the reason why I don't use option 3 either.
>
> The other reason is that some implementations (SBCL at least) issues
> error message.  That's where I know about this restriction from.

Ah, ok.

>>> As I cannot change initargs of effective slot, I also have to set  
>>> some
>>> slots in COMPUTE-EFFECTIVE-SLOT-DEFINITION after calling
>>> CALL-NEXT-METHOD.
>>
>> Exactly.
>
> But this is so inconvenient!  There are good-working mechanics of
> initargs, and I cannot use it!
>
>>> It is so pity that COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS is not
>>> part of the MOP.  As I checked, C-E-S-D-I is defined in CMUCL/SBCL,
>>> LispWorks, Allegro CL and Clisp (where it is exported symbol).   
>>> Is it
>>> worth making CLOSER-MOP-EXT package where useful extensions like
>>> C-E-S-D-I are collected?
>>
>> Are they documented anywhere?
>
> C-E-S-D-I is documented in Clisp Implementation Notes.  Other
> implementations have C-E-S-D-I unexported (as part of PCL
> implementation).

OK, this looks indeed like a good and convenient addition to the  
protocol. I will add this to my ever growing todo list for a possible  
revision of the CLOS MOP spec. (Don't hold your breath. Don't even  
think about holding your breath!)

Maybe such additions are also good candidates for CDRs...



Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium