Hello.
First question: can I access a slot with :class allocation without having
an instance of the class? As much as I see this is not possible in a
portable way.
If not, second question: wouldn't it be useful to have such a possibility
(this per-class data could then be used already during instance creation)?
Thanks for any insights, Nicolas.
From: Frode Vatvedt Fjeld
Subject: Re: Accessing a per-class slot without an instance
Date:
Message-ID: <2h65elzkjs.fsf@vserver.cs.uit.no>
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> First question: can I access a slot with :class allocation without
> having an instance of the class? As much as I see this is not
> possible in a portable way. [..]
>
> Thanks for any insights, Nicolas.
One insight is that class-allocated slots that you find yourself
wanting to access outside the context of an instance, is quite often
better modelled as a global variable.
If you "just want to do it", it's often possible to use
mop:class-prototype to obtain an instance that can be passed to an
accessor. For example:
(slot-value (mop:class-prototype (find-class 'the-class-name))
'the-slot-name)
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> One insight is that class-allocated slots that you find yourself wanting
> to access outside the context of an instance, is quite often better
> modelled as a global variable.
Maybe you are right here. But, I would nevertheless prefer the per-class
slot, mainly because of performance reasons. I think that the access
instance->class->per-class-slot might be better optimized than using a
class-indexed table or a generic function which returns the data. It also
looks nicer IMO (and we have per-class slots, so we should use them:-).
Nicolas.
From: Frode Vatvedt Fjeld
Subject: Re: Accessing a per-class slot without an instance
Date:
Message-ID: <2hr7x9y0d3.fsf@vserver.cs.uit.no>
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> [..] But, I would nevertheless prefer the per-class slot, mainly
> because of performance reasons. I think that the access
> instance->class->per-class-slot might be better optimized than using a
> class-indexed table or a generic function which returns the data.
I think you might be in for a surprise here. At least I would not be
very surprised if accessing a class-allocated slot turned out to
involve several calls to generic functions. And I'd be _very_
surprised if it turned out to be faster (or nearly as fast) as the
obvious global variable scheme.
> It also looks nicer IMO (and we have per-class slots, so we should
> use them:-).
Well.. in my book, the class-prototype hack is ugliness to be avoided
at almost all cost.
In fact, I consider the class-allocated slots to be almost a
misfeature of CLOS. It's unlispy to hide away what is global state
like that. And you don't want to be unlispy, do you? We're all good
patriots here, right? :-)
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
>
> > [..] But, I would nevertheless prefer the per-class slot, mainly
> > because of performance reasons. I think that the access
> > instance->class->per-class-slot might be better optimized than using a
> > class-indexed table or a generic function which returns the data.
>
> I think you might be in for a surprise here. At least I would not be
> very surprised if accessing a class-allocated slot turned out to
> involve several calls to generic functions. And I'd be _very_
> surprised if it turned out to be faster (or nearly as fast) as the
> obvious global variable scheme.
OK, I had hoped for Gerd Moellmann's recent slot optimization for CMUCL.
But I will have to check this more precisely if this is really a reasonable
assumption.
> > It also looks nicer IMO (and we have per-class slots, so we should
> > use them:-).
>
> Well.. in my book, the class-prototype hack is ugliness to be avoided
> at almost all cost.
>
> In fact, I consider the class-allocated slots to be almost a
> misfeature of CLOS. It's unlispy to hide away what is global state
> like that. And you don't want to be unlispy, do you? We're all good
> patriots here, right? :-)
After some pondering I am inclined to believe you. I will change this or
at least keep the interface so abstract that I can plug in also other
implementations.
It would interest me, though, if other people have a convincing use of
per-class allocated slots. As much as I see, usually one will need the
slot to have different values for each subclass (or some of the subclasses,
which complicates matters even more).
Nicolas.
From: Rahul Jain
Subject: Re: Accessing a per-class slot without an instance
Date:
Message-ID: <871xp5rn04.fsf@nyct.net>
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> It would interest me, though, if other people have a convincing use of
> per-class allocated slots. As much as I see, usually one will need the
> slot to have different values for each subclass (or some of the subclasses,
> which complicates matters even more).
From DefDoc/src/elements/basic-elements.lisp:
(defclass discretionary-break (penalty-node)
((pre-break-elements :type list
:initform nil
:initarg pre-break-elements
:accessor pre-break-elements
:documentation "The text to precede the break if it is used.")
(post-break-elements :type list
:initform nil
:initarg post-break-elements
:accessor post-break-elements
:documentation "The text to follow the break if it is used.")
(no-break-elements :type list
:initform nil
:initarg no-break-elements
:accessor no-break-elements
:documentation "The text to be placed here if the break is not used."))
(:documentation "A location where a break can be placed, if necessary."))
(defclass discretionary-hyphen (discretionary-break)
((pre-break-elements #-pcl :type #-pcl (cons * null)
:reader pre-break-elements
:documentation "Initialize this with the 'HYPHEN-CHAR initarg.")
(post-break-elements :type null :allocation :class)
(no-break-elements :type null :allocation :class)
(break-penalty :type null :allocation :class)))
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
There's a general caveat about using class-prototype, particularly for an
internal class which is always constructed in some special way. Creating the
prototype may bypass the normal construction wrapper and use (make-instance
'my-class) to produce the prototype. You may have to take more trouble with
the default initargs or initforms if the prototype is used or override
class-prototype for the class in question.
The extreme case would be a class that is supposed to be instantiated in
production exactly once, but in development uses some non-default arguments.
E.g.:
(make-instance 'nuclear-winter :just-testing t) ; in development
might produce a disastrous class-prototype behind the scenes via
(make-instance 'nuclear-winter)
Jeff
"Frode Vatvedt Fjeld" <······@cs.uit.no> wrote in message
···················@vserver.cs.uit.no...
> Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>
...
> If you "just want to do it", it's often possible to use
> mop:class-prototype to obtain an instance that can be passed to an
> accessor. For example:
>
> (slot-value (mop:class-prototype (find-class 'the-class-name))
> 'the-slot-name)
Jeff Greif wrote:
> There's a general caveat about using class-prototype, particularly for an
> internal class which is always constructed in some special way. Creating the
> prototype may bypass the normal construction wrapper and use (make-instance
> 'my-class) to produce the prototype. You may have to take more trouble with
> the default initargs or initforms if the prototype is used or override
> class-prototype for the class in question.
>
> The extreme case would be a class that is supposed to be instantiated in
> production exactly once, but in development uses some non-default arguments.
This is a very broken model, i.e., an `incorrect' way to think about a
class-allocated slot. Lot's of programmers make this mistake, thinking
of a class-allocated slot as being an attribute of the class. It is not.
A class-allocated slot is an attribute of an instance, not a class, just
like an instance-allocated slot, notwithstanding the fact that its value
is shared by all instances. This fact is not altered by the obvious
implementation which would store the value somewhere in the class object
rather than trying to maintain its direct association with each and every
instance.
In other words, it is incorrect to think of the value of a class slot
separated from any particular instance, and once you don't think about
a class slot in that incorrect way, the question how to access the slot
that way becomes less meaningful.
>> (slot-value (mop:class-prototype (find-class 'the-class-name))
>> 'the-slot-name)
On the other hand, the above is quite legitimate. But it has subtle
differences from a regular call to slot-value. It is inconceivable to
call slot-value on an instance of a class without having an instance
of the class; therefore, it is impossible to call slot-value on an
instance of a class that is not yet finalized. But the above code is
required to signal error if the class is not yet finalized. A
cautious programmer might add a call to finalize-inheritance if he
was not sure the class would already be finalized, and if he was sure
that finalizing the class was indeed possible at the time of the
execution.
The efficiency issue might be addressed this way.
(slot-value (load-time-value
(mop:class-prototype
(let ((c (find-class 'the-class-name)))
(finalize-inheritance c)
c)
'the-slot-name)
But observe that this shifts the question whether the class is
finalizable from run time to load time.
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Jeff Greif wrote:
> > There's a general caveat about using class-prototype, particularly for an
> > internal class which is always constructed in some special way. Creating the
> > prototype may bypass the normal construction wrapper and use (make-instance
> > 'my-class) to produce the prototype. You may have to take more trouble with
> > the default initargs or initforms if the prototype is used or override
> > class-prototype for the class in question.
> >
> > The extreme case would be a class that is supposed to be instantiated in
> > production exactly once, but in development uses some non-default arguments.
>
> This is a very broken model, i.e., an `incorrect' way to think about a
> class-allocated slot. Lot's of programmers make this mistake, thinking
> of a class-allocated slot as being an attribute of the class. It is not.
> A class-allocated slot is an attribute of an instance, not a class, just
> like an instance-allocated slot, notwithstanding the fact that its value
> is shared by all instances. This fact is not altered by the obvious
> implementation which would store the value somewhere in the class object
> rather than trying to maintain its direct association with each and every
> instance.
>
> In other words, it is incorrect to think of the value of a class slot
> separated from any particular instance, and once you don't think about
> a class slot in that incorrect way, the question how to access the slot
> that way becomes less meaningful.
I haven't been paying much attention to this thread, so excuse this
post if it's already been mentioned, but: is the point of all of this
to get something like a "class member" like in other OOP languages?
Most other languages don't have something like class-allocated slots.
CL does have class slots, though: slots are defined in classes, and
exist in instances of that class, so if you want to have a certain
slot in your class object, define it in its class, ie, the class
metaclass. Then you can say:
(defclass my-class ()
()
(:metaclass my-class-metaclass))
(slot-value (find-class 'my-class) 'some-slot)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> I haven't been paying much attention to this thread, so excuse this
> post if it's already been mentioned, but: is the point of all of this
> to get something like a "class member" like in other OOP languages?
A thoroughly ahistorical question. You should ask instead what these
other OOP languages intended with _their_ class members.
Class-allocated are slots precisely so they can be accessed as a slot,
in the same manner as instance-allocated slots.
> Most other languages don't have something like class-allocated slots.
> CL does have class slots, though: slots are defined in classes, and
> exist in instances of that class, so if you want to have a certain
> slot in your class object, define it in its class, ie, the class
> metaclass. Then you can say:
>
> (defclass my-class ()
> ()
> (:metaclass my-class-metaclass))
>
> (slot-value (find-class 'my-class) 'some-slot)
Just so no one else misunderstands, you omitted the implied
definition of the metaclass:
(defclass my-class-metaclass (standard-class)
((some-slot ...)))
You are precisely correct. A slot of a metaclass is much more like
a Java or C++ class member. It belongs to the class metaobject and
is accessed as a slot in the class metaobject. Java (more or less)
and especially C++ don't treat metaobjects as first-class objects
at run time. (Java can, I guess, but it is not idiomatic to do so.)
Therefore they don't need to differentiate between the instance and
the class metaobject, and they can't really differentiate. Class
members and instance members are accessed in the same way and with
the sort of the same syntax.
Anyway, a slot in a class metaobject doesn't depend on the class
being finalized, or upon any instances being handy. It is indeed
rather more like a Java class member than is a class-allocated slot,
but only because Java doesn't make much of the notion of an
unfinalized class.
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I haven't been paying much attention to this thread, so excuse this
> post if it's already been mentioned, but: is the point of all of this
> to get something like a "class member" like in other OOP languages?
> Most other languages don't have something like class-allocated slots.
> CL does have class slots, though: slots are defined in classes, and
> exist in instances of that class, so if you want to have a certain
> slot in your class object, define it in its class, ie, the class
> metaclass. Then you can say:
>
> (defclass my-class ()
> ()
> (:metaclass my-class-metaclass))
>
> (slot-value (find-class 'my-class) 'some-slot)
The thread starts with a question of mine here:
······················································@ortler.iwr.uni-heidelberg.de%3E
Your solution is the same as Pascal Costanza's and it is probably the best
one. At the moment, I have followed Frode's advice and eliminated the slot
with :allocation :class in favor of storing my data as a property on the
class symbol.
I have tried also the metaclass approach (with CMUCL) but have run into a
problem with inheritance. I had to define a method on
PCL:VALIDATE-SUPERCLASS to make it work (thus, it would leave the ANSI
region).
Nicolas.
P.S.: Here is my test code:
(defclass cell-class (standard-class)
((information :accessor cell-class-information :initarg :information)))
(defmethod pcl:validate-superclass ((sub-class cell-class) (super-class standard-class))
t)
(defclass <cell> ()
()
(:documentation "The basic cell class."))
(defclass pyramid (<cell>)
()
(:metaclass cell-class))
;;; The cell-class-information slot would then be initialized after
;;; constructing a reference instance of pyramid.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> I have tried also the metaclass approach (with CMUCL) but have run into a
> problem with inheritance. I had to define a method on
> PCL:VALIDATE-SUPERCLASS to make it work (thus, it would leave the ANSI
> region).
>
> (defclass cell-class (standard-class)
> ((information :accessor cell-class-information :initarg :information)))
>
> (defmethod pcl:validate-superclass ((sub-class cell-class) (super-class standard-class))
> t)
BTW, I have seen code that conditionally includes validate-superclass
only for CMUCL (and/or SBCL, SCL) several times. It is, however,
documented in the AMOP (pg. 240), and the description there reads as
if defining such a method would indeed be required. Then again,
validate-superclass doesn't seem to be mentioned anywhere else in
AMOP, and it is certainly not a part of ANSI CL (but ANSI doesn't say
much about metaclasses anyway).
Do other Lisps completely ignore validate-superclass? Do they have
default methods returning t (not following the AMOP spec), so that you
can prevent incompatible combinations, but don't have to bother in the
common case? Do the differences have any interesting reason?
Henrik Motakef wrote:
> Do other Lisps completely ignore validate-superclass? Do they have
> default methods returning t (not following the AMOP spec), so that you
> can prevent incompatible combinations, but don't have to bother in the
> common case? Do the differences have any interesting reason?
VALIDATE-SUPERCLASS shouldn't return true by default. The potential
problems new class metaobjects may introduce can be very subtle and you
really need to know what you do when you declare compatibility between
class metaobjects.
Sure, it's a pity that you cannot simply add slots to class metaobjects
because of this restriction, but the MOP is designed to allow for many
more things beyond that.
The book "Putting Metaclasses to Work" by Ira Forman and Scott Danforth
explains the issues in more detail. It is based on C++, but is still a
very good read. Unfortunately, it's out of print. (They have some papers
on their websites that seem to deal with the same topic, but I haven't
checked them.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Lord Isildur <·······@andrew.cmu.edu> writes:
> test message, please ignore
Your test failed!
To get successful tests, please use, for example: alt.fr.test.test.test.test
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> First question: can I access a slot with :class allocation without having
> an instance of the class? As much as I see this is not possible in a
> portable way.
Well, I guess you could use class-prototype, which is portable
modulo MOP, at least.
CL-USER 3 > (defclass gazonk ()
((foo :initform "boo" :allocation :class :accessor foo-of)))
#<STANDARD-CLASS GAZONK 100D5807>
CL-USER 4 > (class-prototype (find-class 'gazonk))
#<GAZONK 100C9ACF>
CL-USER 5 > (foo-of *)
"boo"
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>
> > First question: can I access a slot with :class allocation without having
> > an instance of the class? As much as I see this is not possible in a
> > portable way.
>
> Well, I guess you could use class-prototype, which is portable
> modulo MOP, at least.
>
> CL-USER 3 > (defclass gazonk ()
> ((foo :initform "boo" :allocation :class :accessor foo-of)))
> #<STANDARD-CLASS GAZONK 100D5807>
>
> CL-USER 4 > (class-prototype (find-class 'gazonk))
> #<GAZONK 100C9ACF>
>
> CL-USER 5 > (foo-of *)
> "boo"
Thanks for the answer (also to Frode). Looking at your code I see another
possible solution. Maybe I should change my class initialization (done in
a macro) so that a good :initform value is passed. Up to now, I have used
a separate setup function, but perhaps this is the true error.
Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Thanks for the answer (also to Frode). Looking at your code I see another
> possible solution. Maybe I should change my class initialization (done in
> a macro) so that a good :initform value is passed. Up to now, I have used
> a separate setup function, but perhaps this is the true error.
I should have thought a little longer. This does solve only the smaller
part of the problem.
Thanks for all answers, Nicolas.
Nicolas Neuss wrote:
> Hello.
>
> First question: can I access a slot with :class allocation without having
> an instance of the class? As much as I see this is not possible in a
> portable way.
>
> If not, second question: wouldn't it be useful to have such a possibility
> (this per-class data could then be used already during instance creation)?
>
> Thanks for any insights, Nicolas.
Others have already pointed to CLASS-PROTOTYPE. It's easy to get a
similar effect via ALLOCATE-INSTANCE when your Common Lisp doesn't
provide CLASS-PROTOTYPE. Probably the best idea would be to write your
own CLASS-PROTOTYPE that creates singletons via ALLOCATE-INSTANCE. (The
important bit here is that ALLOCATE-INSTANCE doesn't perform any
initialization of an allocated object, so it doesn't hurt your other code.)
Another option would be to subclass STANDARD-CLASS and use it as a
metaclass. The you could access class-specific variables via the class
metaobject created like that.
(defclass my-metaclass (standard-class)
((info :accessor my-info :initarg :my-info)))
(defclass myclass()
(...)
(:metaclass my-metaclass)
(:my-info 4711))
(my-info (find-class 'myclass))
This is untested code. I don't think you need the MOP for doing this,
but I am not 100% sure.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> (defclass my-metaclass (standard-class)
> ((info :accessor my-info :initarg :my-info)))
>
> (defclass myclass()
> (...)
> (:metaclass my-metaclass)
> (:my-info 4711))
>
> (my-info (find-class 'myclass))
>
> This is untested code. I don't think you need the MOP for doing this,
> but I am not 100% sure.
No, this is not covered by ANSI CL. ANSI CL doesn't define that extra
class options are passed over to the initialization / reinitialization
of class metaobjects.
However, I still think that apart from that, it's possible to use
subclasses of STANDARD-CLASS. At least, ANSI CL doesn't seem to forbid
them. You only have to manually take care of initialization of slots in
class metaobjects.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Nicolas Neuss wrote:
>
> > Hello.
> > First question: can I access a slot with :class allocation without having
> > an instance of the class? As much as I see this is not possible in a
> > portable way.
> > If not, second question: wouldn't it be useful to have such a possibility
> > (this per-class data could then be used already during instance creation)?
> > Thanks for any insights, Nicolas.
>
> Others have already pointed to CLASS-PROTOTYPE. It's easy to get a similar
> effect via ALLOCATE-INSTANCE when your Common Lisp doesn't provide
> CLASS-PROTOTYPE. Probably the best idea would be to write your own
> CLASS-PROTOTYPE that creates singletons via ALLOCATE-INSTANCE. (The
> important bit here is that ALLOCATE-INSTANCE doesn't perform any
> initialization of an allocated object, so it doesn't hurt your other code.)
Probably this is the easiest and best option.
> Another option would be to subclass STANDARD-CLASS and use it as a
> metaclass. The you could access class-specific variables via the class
> metaobject created like that.
>
> (defclass my-metaclass (standard-class)
> ((info :accessor my-info :initarg :my-info)))
>
> (defclass myclass()
> (...)
> (:metaclass my-metaclass)
> (:my-info 4711))
>
> (my-info (find-class 'myclass))
As I say in another message, I am partially using this for fast access to
some data I need when processing the instances. I could imagine that using
metaclasses might break slot access optimizations which.[1]
Thanks, Nicolas.
[1] I know that I should probably profile this and that premature
optimization is the root of all evil, but maybe I can avoid some problems
also beforehand without trying them out (on several implementations, of
course:).
Nicolas Neuss wrote:
> As I say in another message, I am partially using this for fast access to
> some data I need when processing the instances. I could imagine that using
> metaclasses might break slot access optimizations
I would rather think not. Metaobjects are plain objects like any other
object, so I don't see why slot accesses should be handled differently.
But you're right, this can probably only be determined by a profiler. ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Nicolas Neuss wrote:
>
> > As I say in another message, I am partially using this for fast access to
> > some data I need when processing the instances. I could imagine that using
> > metaclasses might break slot access optimizations
>
> I would rather think not. Metaobjects are plain objects like any other
> object, so I don't see why slot accesses should be handled differently.
OK, I think this is correct. So this approach should also be reasonable.
> But you're right, this can probably only be determined by a profiler. ;)
OK, you have convinced me that I will have to check this more carefully. I
guess that I will follow Frode's advice and drop those per-class slots.
Nicolas.
From: Bulent Murtezaoglu
Subject: Re: Accessing a per-class slot without an instance
Date:
Message-ID: <87ad3x7fjr.fsf@cubx.internal>
>>>>> "NN" == Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
NN> Hello. First question: can I access a slot with :class
NN> allocation without having an instance of the class? As much
NN> as I see this is not possible in a portable way.
I think you are correct. (this should be in a FAQ actually) See threads
beginning with:
http://groups.google.com/groups?selm=878ylwr5pb.fsf%40cubx.internal
http://groups.google.com/groups?selm=3E81BAF8.4030608%40eurocom.od.ua
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "NN" == Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>
> NN> Hello. First question: can I access a slot with :class
> NN> allocation without having an instance of the class? As much
> NN> as I see this is not possible in a portable way.
>
> I think you are correct. (this should be in a FAQ actually) See threads
> beginning with:
>
> http://groups.google.com/groups?selm=878ylwr5pb.fsf%40cubx.internal
>
> http://groups.google.com/groups?selm=3E81BAF8.4030608%40eurocom.od.ua
>
> cheers,
>
> BM
Apparently, I have overlooked those threads. Thanks for reminding me.
Nicolas.