On 10 Jan 2011, at 19:58, Samium Gromoff wrote:
> On Mon, 10 Jan 2011 18:33:17 GMT, Martin Simmons wrote:
>> Another reason why this won't work is that you only have one slot -- the same
>> value is shared between every subclass of vcs-type-mixin. Adding a separate
>> slot to each subclass is a
That sounds like a good way for it to work.
I'm not sure how safe it would be to depend on each
of the extant implementation of Common Lisp to
do this. It would probably be best if they all
conformed; the only drawback would be the
tiny possibility that some code somewhere is
depending on the ex
On Mon, 10 Jan 2011 18:33:17 GMT, Martin Simmons wrote:
> Another reason why this won't work is that you only have one slot -- the same
> value is shared between every subclass of vcs-type-mixin. Adding a separate
> slot to each subclass is a pain.
Oh, right, my fault here. I remember elaborate
> On Sat, 08 Jan 2011 18:07:48 +0300, Samium Gromoff said:
>
> On Sat, 8 Jan 2011 15:48:33 +0100, Pascal Costanza wrote:
> >
> > On 8 Jan 2011, at 14:15, Samium Gromoff wrote:
> >
> > > On Fri, 7 Jan 2011 23:42:23 +0100, Pascal Costanza wrote:
> > >> There is no real advantage in having sh
On Sat, 8 Jan 2011 15:48:33 +0100, Pascal Costanza wrote:
>
> On 8 Jan 2011, at 14:15, Samium Gromoff wrote:
>
> > On Fri, 7 Jan 2011 23:42:23 +0100, Pascal Costanza wrote:
> >> There is no real advantage in having shared slots over global special
> >> variables. On top of that, the slot access
On 8 Jan 2011, at 14:15, Samium Gromoff wrote:
> On Fri, 7 Jan 2011 23:42:23 +0100, Pascal Costanza wrote:
>> There is no real advantage in having shared slots over global special
>> variables. On top of that, the slot access protocols in the CLOS MOP
>> also don't work that well in conjunction
On 8 Jan 2011, at 11:22, Faré wrote:
>>> Daniel Weinreb wrote:
>>> - however, nothing tells us that the resulting value is used immediately
>>> to initialize the slot (it could just be stored somewhere), and
>>> implementations seem to be free to do so right now, or later when the
>>> first in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Am 08.01.2011 11:22, schrieb Faré:
>>> Daniel Weinreb wrote:
>>> - however, nothing tells us that the resulting value is used immediately
>>> to initialize the slot (it could just be stored somewhere), and
>>> implementations seem to be free to
On Fri, 7 Jan 2011 23:42:23 +0100, Pascal Costanza wrote:
> There is no real advantage in having shared slots over global special
> variables. On top of that, the slot access protocols in the CLOS MOP
> also don't work that well in conjunction with shared slots. So it's
> better to avoid them. For
>> Daniel Weinreb wrote:
>> - however, nothing tells us that the resulting value is used immediately
>> to initialize the slot (it could just be stored somewhere), and
>> implementations seem to be free to do so right now, or later when the
>> first instance is created.
>
> Pascal Costanza wrot
On 6 Jan 2011, at 18:03, Didier Verna wrote:
> Daniel Weinreb wrote:
>
>> This conversation has been good.
>
> Yup. Here's what I gather from it, mostly:
>
> - a shared slot's initform is required to be evaluated when the class is
> created,
I agree here.
> - however, nothing tells us that
> On Thu, 06 Jan 2011 11:44:13 -0500, Daniel Weinreb said:
>
> If you have class c1 with shared slots cs1 and cs2,
> why not just have two global variables (e.f. defvar)
> called *cs1* and *cs2* sitting next to the defclass?
>
> At least one reason, and maybe the only reason,
> is that the in
Daniel Weinreb wrote:
This conversation has been good. I agree with both Svante
and Scott.
As is often the case with the spec, it is not quite unambiguous.
Oh, and I meant to say that I'm not sure the spec is 100%
clear on which forms are evaluated v. not evaluated, and
whether there
Daniel Weinreb wrote:
> This conversation has been good.
Yup. Here's what I gather from it, mostly:
- a shared slot's initform is required to be evaluated when the class is
created,
- however, nothing tells us that the resulting value is used immediately
to initialize the slot (it could ju
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Am 06.01.2011 13:56, schrieb Martin Simmons:
> On Thu, 06 Jan 2011 10:33:43 +0100, Svante Carl v Erichsen said:
>> Am 06.01.2011 01:31, schrieb Scott L. Burson:
>>> In section 7.1 it says: "The :initform for a shared
>>> slot may be used when defi
This conversation has been good. I agree with both Svante
and Scott.
As is often the case with the spec, it is not quite unambiguous.
It seems to me that the spec is having trouble deciding whether
it is a real, strict, firm language spec, or a useful tutorial/reference
documentation aimed at wh
> On Wed, 05 Jan 2011 16:17:09 +0100, Didier Verna said:
>
> Until now, I've been uncounsiously relying on something that the
> standard does not seem to specify: the fact that shared slots equipped
> with an initform are initialized before the first instance is created:
>
> (defclass test
> On Thu, 06 Jan 2011 10:33:43 +0100, Svante Carl v Erichsen said:
>
> Am 06.01.2011 01:31, schrieb Scott L. Burson:
> > In section 7.1 it says: "The :initform for a shared
> > slot may be used when defining or redefining the class."
>
> I think that this is the most directly applying passage
> On Thu, 6 Jan 2011 12:36:48 GMT, Martin Simmons said:
>
> On Wed, 5 Jan 2011 16:31:31 -0800, Scott L Burson said:
> >
> > I think the sentence from 7.1.3 that you've quoted is intended to
> > apply only to local slots; I think these other two passages make that
> > clear by establishing
> On Wed, 5 Jan 2011 16:31:31 -0800, Scott L Burson said:
>
> I think the sentence from 7.1.3 that you've quoted is intended to
> apply only to local slots; I think these other two passages make that
> clear by establishing that shared slots are indeed initialized at
> defclass time.
I think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Am 06.01.2011 01:31, schrieb Scott L. Burson:
> In section 7.1 it says: "The :initform for a shared
> slot may be used when defining or redefining the class."
I think that this is the most directly applying passage for this
issue. I am not entir
"Scott L. Burson" wrote:
> Oh, and this appears to be a bug in ABCL, since the second passage I
> quoted above _requires_ the :initform to be evaluated at defclass
> time.
That's a good point.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~di
"Svante Carl v. Erichsen" wrote:
> from chapter 7.1.4:
>
> "If a slot has both an :initform form and an :initarg slot option, and
> the initialization argument is defaulted using :default-initargs or is
> supplied to make-instance, the captured :initform form is neither used
> nor evaluated."
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello!
In chapter 7.1.5, the fourth bullet of shared-initialize is:
"Any slots indicated by the second argument that are still unbound at
this point are initialized according to their :initform forms."
There is no hint that "slots" could refer only
On Wed, Jan 5, 2011 at 7:17 AM, Didier Verna wrote:
> Until now, I've been uncounsiously relying on something that the
> standard does not seem to specify: the fact that shared slots equipped
> with an initform are initialized before the first instance is created:
>
> (defclass test () ((slot :all
r...@tuxteam.de wrote:
> On Wed, Jan 05, 2011 at 06:15:34PM +0100, Didier Verna wrote:
>>
>> Tim Bradshaw pointed out that my message was not very clear because the
>> test I gave does not demonstrate that an initform's result is used to
>> initialize the slot early, only at which time a slot is
On Wed, Jan 05, 2011 at 06:15:34PM +0100, Didier Verna wrote:
>
> Tim Bradshaw pointed out that my message was not very clear because the
> test I gave does not demonstrate that an initform's result is used to
> initialize the slot early, only at which time a slot is initialized.
>
> This on the
Tim Bradshaw pointed out that my message was not very clear because the
test I gave does not demonstrate that an initform's result is used to
initialize the slot early, only at which time a slot is initialized.
This on the other hand gets closer to the point:
(defclass test ()
((slot :allocati
The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.
Until now, I've been uncounsiously relying on something that the
standard does not seem to specify: the fact that shared slots equipped
with an initform are initialized before the first instan
29 matches
Mail list logo
