[closer-devel] cross-platform identification of slot-protocol class, metaclass

[Sean Champ]

Hello,

There have been some methods I have defined, which I wanted to specialize on
either the slot-protocol class or slot-protocol metaclass for the current
implementation. 

In PCL environments, I know that those classes are, respectively,
SLOT-OBJECT and SLOT-CLASS (within the correct PCL package, of course). In
other implementations -- my not being aware of how structure classes and
condition classes may be implemented, in those, while they are types of
slot-class in PCL  -- in implementations neither CMUCL nor SBCL, rather, I
had simply used STANDARD-OBJECT and STANDARD-CLASS, respectively.


Upon my having noticed the following, in some older code on my host, and my
now being aware of the closer-mop project, I would like to propose if it 
form would be considered for addition into closer-mop. Of course, the final
form of the implementation-specific code would need to be split, so as to
be added into the support code for each respective implementation.


-------
(export '(+slot-protocol-class+
          +slot-protocol-class+

          ;; type specifiers
          slot-protocol-instance
          slot-protocol-class))


(eval-when (:compile-toplevel :load-toplevel :execute)

(defconstant +slot-protocol-class+
  #+SBCL 'sb-pcl::slot-object
  #+PCL 'pcl::slot-object
  #-(or SBCL PCL) 'standard-object)


(defconstant +slot-protocol-class+
  #+SBCL 'sb-pcl::slot-class
  #+PCL 'pcl::slot-class
  #-(or SBCL PCL) 'standard-object)


)



(deftype slot-protocol-instance ()
  (quote #.+slot-protocol-class+))


(deftype slot-protocol-class ()
  (quote #.+slot-protocol-class+))

-------

I could submit a patch, so as to add that into the closer-mop codebase. I
had wanted to propose the matter, firsly, as I was not aware if it would be
wanted to be added.

Before I would make a patch for it, I would hope if other folks might know
what the correct classes would be, for closer-mop-supported implementations
neither SBCL nor CMUCL. Perhaps STANDARD-OBJECT and STANDARD-CLASS would be
too general, as specializers, in some implementations..


For now, I will leave that stuff defined, as above; it is being added into 
in he Auxiliary Library code to the Tioga Project. If it would be wanted in
closer-mop, I would be glad to remove it from there. 

I consider that it would be appropriate, if forms like the above would be
located in a place more central to the origin of the type specifiers used
in the forms. 

In my own stuff, I need that those forms would be defined, somewhere, so
that those variables may be used in the initialization of method
specializers -- viz. #.+slot-protocol-class+ in the specializer spot to a
standard method lambda-list -- and that those type specifiers would be
available. Initially, those forms will be available in TAL; it should be to
no issue, if they would be made available, most directly, via Closer-MOP.


With a shout-out across the world wide code house, yo'


-- 
Sean Champ
Tioga Project - http://www.common-lisp.net/project/tioga/