Re: [Sbcl-devel] re-issuing modified defclass vs. :default-initargs

Nikodemus Siivola <nikodemus@...> writes:
> 2009/9/18 Christophe Rhodes <csr21@...>:
>
>> I seem to remember having this conversation before: at least AMOP
>> mandates the old (un"fixed") behaviour: there is no
>> :direct-default-initargs argument to ensure-class in the expansion of
>> defclass if no :default-initargs defclass argument is present. CLHS
>> 4.3.6 is unfortunately silent on the issue; the known workaround for the
>> AMOP interpretation is to use (:default-initargs) in the new class
>> definition.
>
> I don't see this requirement in AMOP.
>
> On p. 149 it says
>
> "The default initargs class option, if it is present in the defclass
> form, becomes the value of the :direct-default-initargs keyword
> argument to ensure-class. [...]"
>
> Nowhere in the surrounding text do I see an a specification to the
> effect that an absent DEFCLASS option could not be defaulted, and to
> me the sentence above seems to allow defaulting.
>
> Am I misreading this, or missing something else?
Well, there's the "Initialization of Class Metaobjects" section, which
says
| Unless there is a specific note to the contrary, then during
| reinitialization, if an initialization argument is not supplied, the
| previously stored value is left unchanged.
and there is no such specific note for :direct-default-initargs. On the
other hand, arguably that applies to the initialize-instance &c
initialization protocol, and not to defclass/ensure-class.
So, um. (I'm technically on holiday, so not about to get terribly het
up about this :-)
Cheers,
Christophe

Nikodemus Siivola <nikodemus@...> writes:
> 2008/6/29 Samium Gromoff <_deepfire@...>:
>
>> It appears that re-issuing a defclass without :default-initargs
>> doesn't change the class metaobject's direct-default-initargs slot,
>> in case it previously was non-NIL.
>>
>> Testcase:
>>
>> (defclass a () ((a :initarg :a)) (:default-initargs :a 1))
>>
>> (defclass a () ())
>>
>> (make-instance 'a) => raises an error in sbcl 1.0.16.34:
>>
>> debugger invoked on a SB-PCL::INITARG-ERROR in thread #<THREAD "initial thread" {1002424C21}>:
>> Invalid initialization argument: :A in call for class #<STANDARD-CLASS A>.
>> See also:
>> The ANSI Standard, Section 7.1.2
>
> Thanks for the report -- and patience! Fixed in 1.0.31.14.
I seem to remember having this conversation before: at least AMOP
mandates the old (un"fixed") behaviour: there is no
:direct-default-initargs argument to ensure-class in the expansion of
defclass if no :default-initargs defclass argument is present. CLHS
4.3.6 is unfortunately silent on the issue; the known workaround for the
AMOP interpretation is to use (:default-initargs) in the new class
definition.
If this is going to be an intentional deviation from AMOP, then it needs
to be justified and documented.
Cheers,
Christophe

2009/9/18 Christophe Rhodes <csr21@...>:
> I seem to remember having this conversation before: at least AMOP
> mandates the old (un"fixed") behaviour: there is no
> :direct-default-initargs argument to ensure-class in the expansion of
> defclass if no :default-initargs defclass argument is present. CLHS
> 4.3.6 is unfortunately silent on the issue; the known workaround for the
> AMOP interpretation is to use (:default-initargs) in the new class
> definition.
I don't see this requirement in AMOP.
On p. 149 it says
"The default initargs class option, if it is present in the defclass
form, becomes the value of the :direct-default-initargs keyword
argument to ensure-class. [...]"
Nowhere in the surrounding text do I see an a specification to the
effect that an absent DEFCLASS option could not be defaulted, and to
me the sentence above seems to allow defaulting.
Am I misreading this, or missing something else?
> If this is going to be an intentional deviation from AMOP, then it needs
> to be justified and documented.
I can certainly do that, if this is really contrary to AMOP.
Cheers,
-- Nikodemus

Nikodemus Siivola <nikodemus@...> writes:
> 2009/9/18 Christophe Rhodes <csr21@...>:
>
>> I seem to remember having this conversation before: at least AMOP
>> mandates the old (un"fixed") behaviour: there is no
>> :direct-default-initargs argument to ensure-class in the expansion of
>> defclass if no :default-initargs defclass argument is present. CLHS
>> 4.3.6 is unfortunately silent on the issue; the known workaround for the
>> AMOP interpretation is to use (:default-initargs) in the new class
>> definition.
>
> I don't see this requirement in AMOP.
>
> On p. 149 it says
>
> "The default initargs class option, if it is present in the defclass
> form, becomes the value of the :direct-default-initargs keyword
> argument to ensure-class. [...]"
>
> Nowhere in the surrounding text do I see an a specification to the
> effect that an absent DEFCLASS option could not be defaulted, and to
> me the sentence above seems to allow defaulting.
>
> Am I misreading this, or missing something else?
Well, there's the "Initialization of Class Metaobjects" section, which
says
| Unless there is a specific note to the contrary, then during
| reinitialization, if an initialization argument is not supplied, the
| previously stored value is left unchanged.
and there is no such specific note for :direct-default-initargs. On the
other hand, arguably that applies to the initialize-instance &c
initialization protocol, and not to defclass/ensure-class.
So, um. (I'm technically on holiday, so not about to get terribly het
up about this :-)
Cheers,
Christophe

2009/9/18 Christophe Rhodes <csr21@...>:
> Well, there's the "Initialization of Class Metaobjects" section, which
> says
>
> | Unless there is a specific note to the contrary, then during
> | reinitialization, if an initialization argument is not supplied, the
> | previously stored value is left unchanged.
>
> and there is no such specific note for :direct-default-initargs. On the
> other hand, arguably that applies to the initialize-instance &c
> initialization protocol, and not to defclass/ensure-class.
That's the way I read it. At least the language doesn't seem nowhere
near strong enough to make me think anyone should rely on
default-initargless-DEFCLASS not clearing the existing ones -- though
it seems clear enough that ENSURE-CLASS without
direct-default-initargs should not do that.
Cheers,
-- Nikodemus

Nikodemus Siivola <nikodemus@...> writes:
> 2009/9/18 Christophe Rhodes <csr21@...>:
>
>> | Unless there is a specific note to the contrary, then during
>> | reinitialization, if an initialization argument is not supplied, the
>> | previously stored value is left unchanged.
>>
>> and there is no such specific note for :direct-default-initargs. On the
>> other hand, arguably that applies to the initialize-instance &c
>> initialization protocol, and not to defclass/ensure-class.
>
> That's the way I read it. At least the language doesn't seem nowhere
> near strong enough to make me think anyone should rely on
> default-initargless-DEFCLASS not clearing the existing ones -- though
> it seems clear enough that ENSURE-CLASS without
> direct-default-initargs should not do that.
Righty-ho, then. In that reading, your fix is fine.
Cheers,
Christophe

Nikodemus Siivola <nikodemus <at> random-state.net> writes:
>
> 2009/9/18 Christophe Rhodes <csr21 <at> cantab.net>:
>
> > Well, there's the "Initialization of Class Metaobjects" section, which
> > says
> >
> > | Unless there is a specific note to the contrary, then during
> > | reinitialization, if an initialization argument is not supplied, the
> > | previously stored value is left unchanged.
> >
> > and there is no such specific note for :direct-default-initargs. On the
> > other hand, arguably that applies to the initialize-instance &c
> > initialization protocol, and not to defclass/ensure-class.
>
> That's the way I read it. At least the language doesn't seem nowhere
> near strong enough to make me think anyone should rely on
> default-initargless-DEFCLASS not clearing the existing ones -- though
> it seems clear enough that ENSURE-CLASS without
> direct-default-initargs should not do that.
A co-worker recently came across this behaviour with Alegro CL, where a class
redefinition through such a default-initargless-DEFCLASS didn't clear previous
default initargs. I found this thread while researching the issue and thought I
should mention that the folks at Franz pointed us to AMOP section 5.4.2, p.
149, which contains the following sentence:
"The default initargs class option, if it is present in the
defclass form, becomes the value of the :direct-default-initargs
keyword argument to ensure-class."
In any case, I personally prefer the current SBCL behaviour of clearing
previous default-initargs.
Cheers,
--
Luís Oliveira
<http://r42.eu/~luis&gt;