I tried to implement a singleton class in CLOS by defining a method on
make-instance with an eql specializer:
(defclass a-class ()
(()))
(defvar *a-class-prototype*
(make-instance 'a-class))
(defmethod ((cls (eql (find-class 'a-class))) &rest initargs)
*a-class-prototype*)
In cmucl 18.d on linux I noticed that
(make-instance (find-class 'a-class))
used my method but
(make-instance 'a-class)
did not
Is this allowed behavior or a bug?
I am new to CLOS and I wonder whether this is the correct idiom for
implementing a class that has only one instance?
Thanks in advance
Immanuel
Immanuel Litzroth <·········@enfocus.be> writes:
> I am new to CLOS and I wonder whether this is the correct idiom for
> implementing a class that has only one instance?
Why exactly do you need to do this? You could use a symbol, I suppose.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
>>>>> "Rahul" == Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
Rahul> Immanuel Litzroth <·········@enfocus.be> writes:
>> I am new to CLOS and I wonder whether this is the correct idiom
>> for implementing a class that has only one instance?
Rahul> Why exactly do you need to do this? You could use a symbol,
Rahul> I suppose.
I am programming some things concerning colorspaces & colors. Some
colorspace (rgb, cmyk) are non-configurable, while others take some
parameters. For the non-configurable ones I would like to avoid the
cost of constructing a new object by always returning the same
object.
This is a hobby project which I started to find out how 3 languages
(haskell, lisp, c++) compare in expressing the semantics of
colorspaces.
Immanuel
Immanuel Litzroth <·········@enfocus.be> writes:
[Wanting to use singleton classes...]
> I am programming some things concerning colorspaces & colors. Some
> colorspace (rgb, cmyk) are non-configurable, while others take some
> parameters. For the non-configurable ones I would like to avoid the
> cost of constructing a new object by always returning the same
> object.
That's the definition of a symbol. :)
Note that CLOS is truely polymorphic, so you can treat symbols as
instances:
(defmethod colorspace-blah ((space (eql 'rgb)))
100)
and so on.
The (eql ...) notation means that you're specializing on an object eql
to the one given there. This is known as an "eql specializer" for that
reason.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Immanuel Litzroth wrote:
>
> I tried to implement a singleton class in CLOS by defining a method on
> make-instance with an eql specializer:
>
> (defclass a-class ()
> (()))
>
> (defvar *a-class-prototype*
> (make-instance 'a-class))
>
> (defmethod <sic> ((cls (eql (find-class 'a-class))) &rest initargs)
> *a-class-prototype*)
>
> In cmucl 18.d on linux I noticed that
> (make-instance (find-class 'a-class))
> used my method but
> (make-instance 'a-class)
> did not
This works under ACL5 for Windows:
(defclass singleton-class (standard-class)
())
(defclass c-class ()
()
(:metaclass singleton-class))
(defparameter *c-class-prototype*
(make-instance 'c-class))
(defmethod make-instance ((cls singleton-class) &rest initargs)
*c-class-prototype*)
(make-instance (find-class 'c-class))
(make-instance 'c-class)
> Is this allowed behavior or a bug?
I do not know. FWIW, I have a faint fuzzy recollection about (eql
<class>) not being a viable specializer.
Unless I screwed something up, your formulation did not work at all,
which is at least more consistent. The spec does say make-instance on a
symbol should call m-i on the class.
>
> I am new to CLOS and I wonder whether this is the correct idiom for
> implementing a class that has only one instance?
I do not know, but if you are into singletons I think a metaclass is a
better solution for obvious reasons.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
Immanuel Litzroth <·········@enfocus.be> writes:
> I tried to implement a singleton class in CLOS by defining a method on
> make-instance with an eql specializer:
>
> (defclass a-class ()
> (()))
>
> (defvar *a-class-prototype*
> (make-instance 'a-class))
>
> (defmethod ((cls (eql (find-class 'a-class))) &rest initargs)
> *a-class-prototype*)
>
> In cmucl 18.d on linux I noticed that
> (make-instance (find-class 'a-class))
> used my method but
> (make-instance 'a-class)
> did not
> Is this allowed behavior or a bug?
If I recall correctly, that's an old CMUCL bug. It's got something to
do with cl:find-class and pcl:find-class being different. It has come
up before and dejagoogle should find it.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Immanuel Litzroth <·········@enfocus.be> writes:
> I tried to implement a singleton class in CLOS by defining a method on
> make-instance with an eql specializer:
>
> (defclass a-class ()
> (()))
>
> (defvar *a-class-prototype*
> (make-instance 'a-class))
>
> (defmethod ((cls (eql (find-class 'a-class))) &rest initargs)
> *a-class-prototype*)
You'll need
(defmethod ((cls (eql (pcl:find-class 'a-class))) &rest initargs)
*a-class-prototype*)
for CMUCL, sadly. That is a long-standing problem with CMUCL.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein