I had an error in my code because I instantiated a class (with
make-instance) that shouldn't have been instantiated.
In my application I have a class hierarchy in which only the leaf classes
should be instantiated. To detect this type of error in the future, I
decided to make sure that only leaf classes are instantiated. I did it by
putting something like the following in the :after shared-initialized of the
hierarchies base class.
;; obj is the object that is being created
(assert (not (mop:class-direct-subclasses (class-of obj)))
()
"Cannot make an instance of '~a' because it is not a leaf class"
(class-name (class-of obj))
)
I was wondering:
- Is there a "better" solution to my specific problem (only allowing leaf
classes to be instantiated)
- Are there idioms for explicitly declaring certain classes as 'virtual'
Michael Greenberg
"Michael Greenberg" <··········@scr.siemens.com> wrote in message news:<·····················@iad-read.news.verio.net>...
> I had an error in my code because I instantiated a class (with
> make-instance) that shouldn't have been instantiated.
Wrap a constructor around make-instance, and only use that interface in order
to instantiate an object.
(defclass virtual ()
(...))
(defun make-virtual (args ...)
(make-instance 'virtual args ...))
In article <·····················@iad-read.news.verio.net>,
Michael Greenberg <··········@scr.siemens.com> wrote:
>I had an error in my code because I instantiated a class (with
>make-instance) that shouldn't have been instantiated.
...
>I was wondering:
> - Is there a "better" solution to my specific problem (only allowing leaf
>classes to be instantiated)
Flavors had a keyword :ABSTRACT-FLAVOR that could be included in a flavor
definition, which prevented instantiation of that flavor. It also had
:REQUIRED-METHODS and :REQUIRED-INSTANCE-VARIABLES, which prevented
instantiation of a subflavor unless they were all defined somewhere (in the
case of :REQUIRED-METHODS, it's like C++'s '=0' definition of a member
function in the base class).
None of this was carried over into CLOS, though.
> - Are there idioms for explicitly declaring certain classes as 'virtual'
I think that the :REQUIRED-METHODS option is more likely to be what you
want, since it allows you to check whether the instantiated class
implements the appropriate protocol. You can accomplish this by having a
MAKE-INSTANCE method for the parent class that checks whether the methods
exist. Since the parent class shouldn't define these methods itself, it
will fail if you try to instantiate it.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Barry Margolin" <··············@level3.com> wrote in message
·····················@paloalto-snr1.gtei.net...
> In article <·····················@iad-read.news.verio.net>,
> Michael Greenberg <··········@scr.siemens.com> wrote:
> >I had an error in my code because I instantiated a class (with
> >make-instance) that shouldn't have been instantiated.
> ...
> >I was wondering:
> > - Is there a "better" solution to my specific problem (only allowing
leaf
> >classes to be instantiated)
>
> Flavors had a keyword :ABSTRACT-FLAVOR that could be included in a flavor
> definition, which prevented instantiation of that flavor. It also had
> :REQUIRED-METHODS and :REQUIRED-INSTANCE-VARIABLES, which prevented
> instantiation of a subflavor unless they were all defined somewhere (in
the
> case of :REQUIRED-METHODS, it's like C++'s '=0' definition of a member
> function in the base class).
>
> None of this was carried over into CLOS, though.
>
Could you fix this limited by MOPing ;) CLOS up.
OR, does the AMOP book not provide the
right kind of MOP ;) to sweep these functions
into CLOS.
I'm am just 'ssstarting' using CLOS with LISP, and am
curious.
"Michael Greenberg" <··········@scr.siemens.com> writes:
> I had an error in my code because I instantiated a class (with
> make-instance) that shouldn't have been instantiated.
>
> In my application I have a class hierarchy in which only the leaf classes
> should be instantiated. To detect this type of error in the future, I
> decided to make sure that only leaf classes are instantiated. I did it by
> putting something like the following in the :after shared-initialized of the
> hierarchies base class.
>
> ;; obj is the object that is being created
>
> (assert (not (mop:class-direct-subclasses (class-of obj)))
> ()
> "Cannot make an instance of '~a' because it is not a leaf class"
> (class-name (class-of obj))
> )
>
> I was wondering:
> - Is there a "better" solution to my specific problem (only allowing leaf
> classes to be instantiated)
> - Are there idioms for explicitly declaring certain classes as 'virtual'
In EIEIO (a partial CLOS implementation in emacs lisp), there's
the :abstrat class option.
Options added to EIEIO:
:abstract - Non-nil to prevent instances of this class.
If a string, use as an error string if someone does
try to make an instance.
But CLHS says:
The options to defclass can be extended. It is required that all
implementations signal an error if they observe a class option or a
slot option that is not implemented locally.
so if you want to add this option, you'll have to redefine defclass to
track the abstract status of classes, in addition to processing it in
shared-initialize.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
From: Tim Bradshaw
Subject: Re: Preventing instantiation of 'virtual' classes
Date:
Message-ID: <ey3k7ct1bts.fsf@cley.com>
* Pascal Bourguignon wrote:
> The options to defclass can be extended. It is required that all
> implementations signal an error if they observe a class option or a
> slot option that is not implemented locally.
`implemented locally' can mean `implemented by the metaclass', I
think.
--tim
From: james anderson
Subject: Re: Preventing instantiation of 'virtual' classes
Date:
Message-ID: <3EC2C9C2.2A25245E@setf.de>
one way to do it is to define an abstract metaclass, to specify this as the
metaclass of your virtual classes, and to specialize make-instance for this
metaclass to preclude instantiation. the standard defclass forms is enough for this.
you can extend the constraints a step further, to methods, but defining an
abstract-method class. this requires additional method definition macros, as
you would want to specialize specific methods, which neither defgeneric not
defmethod supports. one can do it by changing the method's class after
definition. a method combination for those functions which are to enforce
concrete methods can then examine the specializers for all applicable methods,
eliminate those defined for abstract classes, and react accordingly if it does
not like what's left.
...
Michael Greenberg wrote:
>
> I had an error in my code because I instantiated a class (with
> make-instance) that shouldn't have been instantiated.
>
> In my application I have a class hierarchy in which only the leaf classes
> should be instantiated. To detect this type of error in the future, I
> decided to make sure that only leaf classes are instantiated. I did it by
> putting something like the following in the :after shared-initialized of the
> hierarchies base class.
>
> ;; obj is the object that is being created
>
> (assert (not (mop:class-direct-subclasses (class-of obj)))
> ()
> "Cannot make an instance of '~a' because it is not a leaf class"
> (class-name (class-of obj))
> )
>
> I was wondering:
> - Is there a "better" solution to my specific problem (only allowing leaf
> classes to be instantiated)
> - Are there idioms for explicitly declaring certain classes as 'virtual'
>
> Michael Greenberg
"Michael Greenberg" <··········@scr.siemens.com> writes:
> I had an error in my code because I instantiated a class (with
> make-instance) that shouldn't have been instantiated.
>
> In my application I have a class hierarchy in which only the leaf classes
> should be instantiated. To detect this type of error in the future, I
> decided to make sure that only leaf classes are instantiated. I did it by
> putting something like the following in the :after shared-initialized of the
> hierarchies base class.
>
> ;; obj is the object that is being created
>
> (assert (not (mop:class-direct-subclasses (class-of obj)))
> ()
> "Cannot make an instance of '~a' because it is not a leaf class"
> (class-name (class-of obj))
> )
>
> I was wondering:
> - Is there a "better" solution to my specific problem (only allowing leaf
> classes to be instantiated)
> - Are there idioms for explicitly declaring certain classes as 'virtual'
I use a DEFINE-ABSTRACT-CLASS macro that works just like DEFCLASS, but
also defines a method on MAKE-INSTANCE. It also adds a note to the
docstring, which we've found to be useful:
(define-condition instantiating-abstract-class (error)
((class :reader instantiating-abstract-class.class :initarg class))
(:report (lambda (condition stream)
(format stream "Tried to instantiate abstract class ~S"
(class-name (instantiating-abstract-class.class condition))))))
(defvar *abstract-class-signal-error* t "See DEFINE-ABSTRACT-CLASS.")
(defmacro define-abstract-class (name superclasses &optional slot-specs &rest class-options)
"Define an abstract class, with a note indicating it's abstract added
to its docstring. If *ABSTRACT-CLASS-SIGNAL-ERROR* is non-nil when defining
a class, it causes a continuable error of type INSTANTIATING-ABSTRACT-CLASS
to be raised if the user tries to make an instance of it directly."
(let ((documentation (second (assoc :documentation class-options)))
(other-options (remove :documentation class-options :key #'first)))
(setf documentation
(etypecase documentation
(null "Abstract class.")
(string (concatenate 'string "ABSTRACT CLASS: " documentation))))
`(prog1
(defclass ,name ,superclasses ,slotspecs
,documentation ,@other-options)
,@(when *abstract-class-signal-error*
`((defmethod make-instance ((class (eql (find-class (quote ,name))))
&rest stuff)
"Raise a continuable error if making precisely this class."
(declare (ignore stuff))
(cerror "Make an instance anyway."
'instantiating-abstract-class 'class class)
(when (next-method-p)
(call-next-method))))))))
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Steven M. Haflich
Subject: Re: Preventing instantiation of 'virtual' classes
Date:
Message-ID: <3EC7A1D9.9040805@alum.mit.edu>
Thomas F. Burdick wrote:
> I use a DEFINE-ABSTRACT-CLASS macro that works just like DEFCLASS, but
> also defines a method on MAKE-INSTANCE. It also adds a note to the
> docstring, which we've found to be useful:
> ...
> ,@(when *abstract-class-signal-error*
> `((defmethod make-instance ((class (eql (find-class (quote ,name))))
> &rest stuff)
> "Raise a continuable error if making precisely this class."
> (declare (ignore stuff))
> (cerror "Make an instance anyway."
> 'instantiating-abstract-class 'class class)
> (when (next-method-p)
> (call-next-method))))))))
I would be cautious about defining lots of eql methods on mainline
functions that may get called at high bandwidth. Such solutions might
not scale well. Implementations do a lot of clever things to optimize
instance creation, and the existence of eql methods on any of the
standard instance creation/initialization functions may preclude these
optimizations.
The distinction you are trying to make is exactly embodied by a
metaclass:
(defclass abstract-class (standard-class) () ())
(defmethod make-instance ((class abstract-class) &rest initargs)
(declare (ignore initargs))
(error "Attempt to instantiate abstract class: ~s" class))
The above doesn't even require the mop, but solutions built on
make-instance aren't quite irontight as they permit change-class
to construct instances. It is better instead to prevent an
abstract class from being finalized, which closes off this
possibility. So instead:
(defmethod mop:finalize-inheritance ((class abstract-class))
(error "Attempt to finalize abstract class: ~s" class))
Anyway, with a metaclass-based solution there is at make-instance time
no residue of the additional method(s) because they are not applicable
to the metaclass being instantiated. The reason eql methods might fail
to scale well is that they might not easily be eliminated by the regular
optimized (and caching) class-based descrimination done by the several
geenric functions involved in instantiation.
On the other hand, I suspect what you really want is some sort of
required-methods notion instead of an abstract-class. There are several
places in the MOP you could hook to implement that...
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Thomas F. Burdick wrote:
>
> > I use a DEFINE-ABSTRACT-CLASS macro that works just like DEFCLASS, but
> > also defines a method on MAKE-INSTANCE. It also adds a note to the
> > docstring, which we've found to be useful:
> > ...
> > ,@(when *abstract-class-signal-error*
> > `((defmethod make-instance ((class (eql (find-class (quote ,name))))
> > &rest stuff)
> > "Raise a continuable error if making precisely this class."
> > (declare (ignore stuff))
> > (cerror "Make an instance anyway."
> > 'instantiating-abstract-class 'class class)
> > (when (next-method-p)
> > (call-next-method))))))))
>
> I would be cautious about defining lots of eql methods on mainline
> functions that may get called at high bandwidth. Such solutions might
> not scale well. Implementations do a lot of clever things to optimize
> instance creation, and the existence of eql methods on any of the
> standard instance creation/initialization functions may preclude these
> optimizations.
This is true. I think I did it this way because it needed to work in
CLISP. Either way, code that uses this normally runs without that
method defined.
> The distinction you are trying to make is exactly embodied by a
> metaclass:
>
> (defclass abstract-class (standard-class) () ())
>
> (defmethod make-instance ((class abstract-class) &rest initargs)
> (declare (ignore initargs))
> (error "Attempt to instantiate abstract class: ~s" class))
>
> The above doesn't even require the mop, but solutions built on
> make-instance aren't quite irontight as they permit change-class
> to construct instances. It is better instead to prevent an
> abstract class from being finalized, which closes off this
> possibility.
Actually, this is probably the best option (combined with a method on
change-class), because it lets you most easily discover who is trying
to make the instance (grovel down the backtrace).
> On the other hand, I suspect what you really want is some sort of
> required-methods notion instead of an abstract-class. There are several
> places in the MOP you could hook to implement that...
No, I'm pretty sure I want abstract classes. Really, they're mixins.
I want to be able to add them to a class's supers and have the code
already written, just work with that class. The joys of MI and all --
the only downside being that you usually want to avoid having
instances of the mixins themselves in your graph (or whatever they're
being used for).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> The distinction you are trying to make is exactly embodied by a
> metaclass:
>
> (defclass abstract-class (standard-class) () ())
You probably meant (defclass abstract-class (standard-class) ())
> (defmethod make-instance ((class abstract-class) &rest initargs)
> (declare (ignore initargs))
> (error "Attempt to instantiate abstract class: ~s" class))
>
> The above doesn't even require the mop, but solutions built on
> make-instance aren't quite irontight as they permit change-class
> to construct instances. It is better instead to prevent an
> abstract class from being finalized, which closes off this
> possibility. So instead:
>
> (defmethod mop:finalize-inheritance ((class abstract-class))
> (error "Attempt to finalize abstract class: ~s" class))
I don't see how this can work. How is one supposed to use
abstract-class if finalizing it results to an error? After all, it
has to be finalized even if you don't instantiate it but only its
subclasses. Or am I missing something?
--
Hannu
From: Steven M. Haflich
Subject: Re: Preventing instantiation of 'virtual' classes
Date:
Message-ID: <3EC96001.1000703@alum.mit.edu>
Hannu Koivisto wrote:
> You probably meant (defclass abstract-class (standard-class) ())
Right, typo.
>> (defmethod mop:finalize-inheritance ((class abstract-class))
>> (error "Attempt to finalize abstract class: ~s" class))
>
> I don't see how this can work. How is one supposed to use
> abstract-class if finalizing it results to an error? After all, it
> has to be finalized even if you don't instantiate it but only its
> subclasses. Or am I missing something?
Yes, you are missing that finalization is _not_ necessary for
a class to a superclass of another class, even if that subclass
is itself finalized.
Informally, finalization consists of determining the layout of the
slots and the class precedence list. Neither of these things is
necessary for a class to serve as a superclass. You can call
mop:finalize-inheritance at any time to try to finalize the class,
but the only time the system will do it for you is when you try
to instantiate the class and it is not already finalized, or
you modify a class or superclass and the class is already finalized.
From: james anderson
Subject: Re: Preventing instantiation of 'virtual' classes
Date:
Message-ID: <3ECCEA93.B23E0A78@setf.de>
?
if you cannot finalize the precedence list, then does that not render the
class useless as a method specializer?
"Steven M. Haflich" wrote:
>
> Hannu Koivisto wrote:
> > You probably meant (defclass abstract-class (standard-class) ())
>
> Right, typo.
>
> >> (defmethod mop:finalize-inheritance ((class abstract-class))
> >> (error "Attempt to finalize abstract class: ~s" class))
> >
> > I don't see how this can work. How is one supposed to use
> > abstract-class if finalizing it results to an error? After all, it
> > has to be finalized even if you don't instantiate it but only its
> > subclasses. Or am I missing something?
>
> Yes, you are missing that finalization is _not_ necessary for
> a class to a superclass of another class, even if that subclass
> is itself finalized.
>
> Informally, finalization consists of determining the layout of the
> slots and the class precedence list. Neither of these things is
> necessary for a class to serve as a superclass. You can call
> mop:finalize-inheritance at any time to try to finalize the class,
> but the only time the system will do it for you is when you try
> to instantiate the class and it is not already finalized, or
> you modify a class or superclass and the class is already finalized.
james anderson <··············@setf.de> writes:
> if you cannot finalize the precedence list, then does that not render the
> class useless as a method specializer?
Not at all.
If a method is called with an argument of type CONCRETE-SUB-CLASS,
which is a sub class of ABSTRACT-SUPER-CLASS, the only precedence list
that is considered is that of CONCRETE-SUB-CLASS.
Stig Hemmer,
Jack of a Few Trades.
"Thomas F. Burdick" <···@avalanche.OCF.Berkeley.EDU> wrote in message
····················@avalanche.OCF.Berkeley.EDU...
> I use a DEFINE-ABSTRACT-CLASS macro that works just like DEFCLASS, but
> also defines a method on MAKE-INSTANCE. It also adds a note to the
> docstring, which we've found to be useful:
>
>
> (define-condition instantiating-abstract-class (error)
> ((class :reader instantiating-abstract-class.class :initarg class))
> (:report (lambda (condition stream)
> (format stream "Tried to instantiate abstract class ~S"
> (class-name (instantiating-abstract-class.class
condition))))))
>
>
> (defvar *abstract-class-signal-error* t "See DEFINE-ABSTRACT-CLASS.")
>
> (defmacro define-abstract-class (name superclasses &optional slot-specs
&rest class-options)
> "Define an abstract class, with a note indicating it's abstract added
> to its docstring. If *ABSTRACT-CLASS-SIGNAL-ERROR* is non-nil when
defining
> a class, it causes a continuable error of type
INSTANTIATING-ABSTRACT-CLASS
> to be raised if the user tries to make an instance of it directly."
> (let ((documentation (second (assoc :documentation class-options)))
> (other-options (remove :documentation class-options :key
#'first)))
> (setf documentation
> (etypecase documentation
> (null "Abstract class.")
> (string (concatenate 'string "ABSTRACT CLASS: "
documentation))))
> `(prog1
> (defclass ,name ,superclasses ,slotspecs
> ,documentation ,@other-options)
>
> ,@(when *abstract-class-signal-error*
> `((defmethod make-instance ((class (eql (find-class (quote
,name))))
> &rest stuff)
> "Raise a continuable error if making precisely this class."
> (declare (ignore stuff))
> (cerror "Make an instance anyway."
> 'instantiating-abstract-class 'class class)
> (when (next-method-p)
> (call-next-method))))))))
I am curious as to why you choose to check *abstract-class-signal-error* at
definition time rather than at run time, mostly because run-time would have
been my intuition. If you use define-abstract-class, well, you want an
abstract class! Why check if the user really means it. I can understand
wanting a switch in there somewhere for debugging or what ever but would
figure it would be more useful to toggle it at run time.
Jus' wonderin...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message
·················@otis.netspace.net.au...
>
> "Thomas F. Burdick" <···@avalanche.OCF.Berkeley.EDU> wrote in message
> ····················@avalanche.OCF.Berkeley.EDU...
> > I use a DEFINE-ABSTRACT-CLASS macro that works just like DEFCLASS, but
> > also defines a method on MAKE-INSTANCE. It also adds a note to the
> > docstring, which we've found to be useful:
> >
> >
> > (define-condition instantiating-abstract-class (error)
> > ((class :reader instantiating-abstract-class.class :initarg class))
> > (:report (lambda (condition stream)
> > (format stream "Tried to instantiate abstract class ~S"
> > (class-name (instantiating-abstract-class.class
> condition))))))
> >
> >
> > (defvar *abstract-class-signal-error* t "See DEFINE-ABSTRACT-CLASS.")
> >
> > (defmacro define-abstract-class (name superclasses &optional slot-specs
> &rest class-options)
> > "Define an abstract class, with a note indicating it's abstract added
> > to its docstring. If *ABSTRACT-CLASS-SIGNAL-ERROR* is non-nil when
> defining
> > a class, it causes a continuable error of type
> INSTANTIATING-ABSTRACT-CLASS
> > to be raised if the user tries to make an instance of it directly."
> > (let ((documentation (second (assoc :documentation class-options)))
> > (other-options (remove :documentation class-options :key
> #'first)))
> > (setf documentation
> > (etypecase documentation
> > (null "Abstract class.")
> > (string (concatenate 'string "ABSTRACT CLASS: "
> documentation))))
> > `(prog1
> > (defclass ,name ,superclasses ,slotspecs
> > ,documentation ,@other-options)
> >
> > ,@(when *abstract-class-signal-error*
> > `((defmethod make-instance ((class (eql (find-class (quote
> ,name))))
> > &rest stuff)
> > "Raise a continuable error if making precisely this
class."
> > (declare (ignore stuff))
> > (cerror "Make an instance anyway."
> > 'instantiating-abstract-class 'class class)
> > (when (next-method-p)
> > (call-next-method))))))))
>
> I am curious as to why you choose to check *abstract-class-signal-error*
at
> definition time rather than at run time, mostly because run time would
have
> been my intuition. If you use define-abstract-class, well, you want an
> abstract class! Why check if the user really means it. I can understand
> wanting a switch in there somewhere for debugging or what ever but would
> figure it would be more useful to toggle it at run time.
Should really have said "instantiation time" above, not "run time".
M-% run time <enter> instantiation time <enter> !
> Jus' wonderin...
Still.. :)
> --
> Coby Beck
> (remove #\Space "coby 101 @ bigpond . com")
>
>
"Coby Beck" <·····@mercury.bc.ca> writes:
> I am curious as to why you choose to check *abstract-class-signal-error* at
> definition time rather than at run time, mostly because run-time would have
> been my intuition. If you use define-abstract-class, well, you want an
> abstract class! Why check if the user really means it. I can understand
> wanting a switch in there somewhere for debugging or what ever but would
> figure it would be more useful to toggle it at run time.
>
> Jus' wonderin...
As Stephen Halfich pointed out, having a lot of EQL methods involved
in instantiation might be a bad thing -- so I wanted to avoid
generating them if they wouldn't be used. In reality, I have
*abstract-class-signal-error* set to nil. The visual distinction in
the source code, and the abstract class note in the docstring is
generally enough. On occasion, though, I've redefined a class with
error signalling on, to make sure it's not being instantiated
directly. A MOP-based solution and an instantiation-time check would
probably be best.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'