[Openmcl-devel] [Re: MOP Question: structure of Lambda list for direct-slot-definition-class]

[rm at fabula.de]

On Wed, Feb 23, 2005 at 04:39:33AM -0700, Gary Byers wrote:
> 
> >  [snip]
> > 
> > while i agree that this (listifying multiple values) is what the mop
> > says i don't think it's the best way to do things.
> >

While i don't think the AMOP way of handling things is the best way of
dealing with the problem i'd hate to have to conditionalize my code for
OpenMCL. 
> 
> I don't believe that you're missing anything (if you are, I'm missing
> it, too.)
> 
> I think that ideally I'd like to have some way of saying that a given
> slot-option can appear at most once (as is true of some of the predefined
> options) and that the associated value should be provided as is (well,
> quoted), or that an option can appear multiple times and have the values
> canonicalized into a list.

Yes, i agree with that. Zhe question is: _where_ does such a syntax check
occur? The problem i reported was with {direct|effective}-slot-definition-class
whose purpose, imhu, is to detect the class used for a slot. In my understanding
the initargs are passed to this function only to detect whether the slot needs
to have a special slot definition at all - this usually seems to be done by
"tagging" the slot with a special init-arg so one can test simply with
a (getf initargs :persistant-slot) or something similar. (In my example
i _extend_ the functionality of clsql so i not only need to test for the
presence of a slot initarg (:db-kind in my case) but also need to test
the _value_ of that initarg).
I think the syntax check for initargs belongs to the instantiation of the
corresponding slot-definition class.

> I agree that what the spec actually says (as reinforced by the example
> in Figure 5.2) seems to be inferior to what I thought it said: option
> values aren't canonicalized consistently, but that's a function of
> the syntax of the call and not an attribute of the option itself (so
> both cases have to be handled for every non-standard option, to the
> extent that that's even possible.)
> 
> Implementing what the spec says would introduce an incompatible change
> (and would, as you point out, likely make it hard to reliably validate
> non-standard slot-option values.)  That's -almost- a compelling argument
> against fixing it, but I'm not sure that it's quite compelling enough.

I don't see why this should make valdation esp. hard. Just don't try to do
it in {direct|effective}-slot-definition-class which is, afaiu not meant for
this task.

> I do think that it may be worth considering having some way of requesting
> the current non-compliant-but-more-consistent behavior (e.g., if
> *DEFCLASS-ALWAYS-LISTIFIES-NON-STANDARD-SLOT-OPTION-VALUES* is true
> at macroexpand time ...).  I keep thinking that the real solution is to
> have something like:
> 
> (define-slot-option-behavior :value-type :at-most-once-and-single-value)
> (define-slot-option-behavior :foreign-reader :allow-multiple-and-listify)
> 
> [The intent would be to define behavior that'd (a) take effect at
>  DEFCLASS  macroexpand time and (b) be a global attribute of the symbol used
>  as a slot option initarg.  If this could be reasonably implemented and
>  used, I'd be less concerned about what the default behavior was.]

Didn't LispWorks have a (non-AMOP) process-a-slot-option which seems like the
right place to do such syntax checks.

 Cheers RalfD

> 
> 
>