;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package CORBA)
(defclass service () ... )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package C++)
(defclass method () ... )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package CORBA-C++)
(defmethod c++-method ((s corba:service))
"return the c++ method associated with the corba service"
(make-instance 'c++:method :return-type 'c++:void) ; where to cache it ?
)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
so i want to use :
(in-package APP)
(corba-c++:c++-method s ) ; where s isa corba:service
But each time i call this form, i create a new instance of c++:method. So i want to cache it somewhere. a hashtable for this seems redondant with the fields of classes.
an idea ?
ctu.
Christophe Turle <······@nospam.fr> writes:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (in-package CORBA)
>
> (defclass service () ... )
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (in-package C++)
>
> (defclass method () ... )
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (in-package CORBA-C++)
>
> (defmethod c++-method ((s corba:service))
> "return the c++ method associated with the corba service"
> (make-instance 'c++:method :return-type 'c++:void) ; where to cache it ?
> )
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> so i want to use :
>
> (in-package APP)
>
> (corba-c++:c++-method s ) ; where s isa corba:service
>
> But each time i call this form, i create a new instance of
> c++:method. So i want to cache it somewhere. a hashtable for this
> seems redondant with the fields of classes.
>
> an idea ?
The most straightforward place to store this is as a slot on the
corba:service object. But I assume you don't want to do that.
Perhaps the CORBA service class presumably shouldn't have any knowledge
or direct support for the c++-method, because that method doesn't always
exist? For example if you want to have a clos-method or some other
method, or perhaps even multiple realizations of the service that are
not necessarily known at the design time of the service class.
In that case, I would suggest having something like a method slot on
SERVICE which would have an association or property list linking the
language, say :c++ to the actual method instance. You could then write
the method something like the following:
(defmethod c++-method ((s corba:service))
"return the c++ method associated with the corba service"
(let ((method (getf :c++ (methods s))))
(when (null method)
(setq method
(make-instance 'c++:method :return-type 'c++:void))
(setf (getf :c++ (methods s)) method))
method))
The information would be cached with the service object itself.
--
Thomas A. Russ, USC/Information Sciences Institute
Christophe Turle wrote:
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (in-package CORBA)
>
> (defclass service () ... )
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (in-package C++)
>
> (defclass method () ... )
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (in-package CORBA-C++)
>
> (defmethod c++-method ((s corba:service))
> "return the c++ method associated with the corba service"
> (make-instance 'c++:method :return-type 'c++:void) ; where to cache it ?
> )
Why is "s" (the corba:service) not referenced above, other than for
method dispatch?
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> so i want to use :
>
> (in-package APP)
>
> (corba-c++:c++-method s ) ; where s isa corba:service
>
> But each time i call this form, i create a new instance of c++:method.
> So i want to cache it somewhere. a hashtable for this seems redondant
> with the fields of classes.
>
> an idea ?
The moral equivalent of what you have would be:
(defclass corba:service ()
((C++-method :allocation :class
:reader c++-method
:initform (make-instance 'c++:method ...etc))))
Your c++-method method is just saying "this type of instance always has
this c++-method", and that sounds more like a class attribute than an
interesting functional result.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> Christophe Turle wrote:
>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>> (in-package CORBA)
>>
>> (defclass service () ... )
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>> (in-package C++)
>>
>> (defclass method () ... )
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>> (in-package CORBA-C++)
>>
>> (defmethod c++-method ((s corba:service))
>> "return the c++ method associated with the corba service"
>> (make-instance 'c++:method :return-type 'c++:void) ; where to cache
>> it ?
>> )
>
>
> Why is "s" (the corba:service) not referenced above, other than for
> method dispatch?
because the return-type is a function of s. not always 'c++:void.
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>> so i want to use :
>>
>> (in-package APP)
>>
>> (corba-c++:c++-method s ) ; where s isa corba:service
>>
>> But each time i call this form,
for the same instance 's' i should have precised. so not a class allocation.
> i create a new instance of c++:method.
>> So i want to cache it somewhere. a hashtable for this seems redondant
>> with the fields of classes.
>>
>> an idea ?
>
>
> The moral equivalent of what you have would be:
>
> (defclass corba:service ()
> ((C++-method :allocation :class
> :reader c++-method
> :initform (make-instance 'c++:method ...etc))))
>
> Your c++-method method is just saying "this type of instance always has
> this c++-method", and that sounds more like a class attribute than an
> interesting functional result.
>
> kt
>
no. because in your code, you have to know about the "c++-method" at the time you write the corba:service class. In my case, it is the class definition. And not all corba:service might have this slot. it is near this :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package CORBA-C++)
(defclass service (( s corba:service ))
( ( c++-method :reader c++-method
:initform (make-instance 'c++:method :return-type (foo s)) )))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
2 problems remain :
1- i should be able to change class at runtime.
(corba:defservice ...) => s isa corba:service
(c++-method s) => change class of s. So s isa corba-c++:service and then return (c++-method s)
how to do thta and what happens if initially s isa subclass of corba:service ? how can i merge the new classes ?
2- the "(defclass service (( s corba:service ))" is not valid. I will search how to retrieve the s to call foo on it.
perhaps reallocate-instance ...
ctu.
Christophe Turle wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Christophe Turle wrote:
>>
>>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>> (in-package CORBA)
>>>
>>> (defclass service () ... )
>>>
>>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>> (in-package C++)
>>>
>>> (defclass method () ... )
>>>
>>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>> (in-package CORBA-C++)
>>>
>>> (defmethod c++-method ((s corba:service))
>>> "return the c++ method associated with the corba service"
>>> (make-instance 'c++:method :return-type 'c++:void) ; where to cache
>>> it ?
>>> )
>>
>>
>>
>> Why is "s" (the corba:service) not referenced above, other than for
>> method dispatch?
>
>
> because the return-type is a function of s. not always 'c++:void.
OK, so the code you showed is the default: a method with return-type void.
Q1. Will the method instance ever contain any info other than
return-type? I am guessing yes.
Q2. Can different instances of the same service class have different
methods/return types? I am guessing yes.
how about:
(make-instance 'corba:service
:c++-method (make-instance c++:method :return-type 'long)
It is not the end of the world if some instances have a nil value in
their c++-method slot, but if you think it worthwhile you could have a
subclass of corba:service for the category of services which need this
(and hopefully other) slot.
>
> (defclass service (( s corba:service ))
> ( ( c++-method :reader c++-method
> :initform (make-instance 'c++:method :return-type (foo s)) )))
As you realize, this will not work. But this at least makes me think
that the only thing that varies is the return-type, so I am not sure why
you need a whole method instance.
btw, one thing you can do is:
(defmethod initialize-instance :after ((s corba:service) &key)
(setf (c++method s) (make-instance 'c++:method
:return-type (foo s))))
> 2 problems remain :
>
> 1- i should be able to change class at runtime.
>
> (corba:defservice ...) => s isa corba:service
>
> (c++-method s) => change class of s. So s isa corba-c++:service and then
> return (c++-method s)
>
> how to do thta and what happens if initially s isa subclass of
> corba:service ? how can i merge the new classes ?
I am afraid you lost me (actual code would be better), but if you mean
to use 'change-class and want the instance which is now a service to
pick up a value for c++-method, use shared-initialize instead of
initialize-instance as shown above. s-i gets called as part of i-i and
other things such as an instance changing class.
>
>
> 2- the "(defclass service (( s corba:service ))" is not valid. I will
> search how to retrieve the s to call foo on it.
That is not really possible in an INITFORM, since the instance being
formed is not accessible to the initform function. For things like this
you need one of the initialize methods I just mentioned.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Christophe Turle wrote:
> no. because in your code, you have to know about the "c++-method" at the
> time you write the corba:service class. In my case, it is the class
> definition. And not all corba:service might have this slot. it is near
> this :
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> (in-package CORBA-C++)
>
> (defclass service (( s corba:service ))
> ( ( c++-method :reader c++-method
> :initform (make-instance 'c++:method :return-type (foo s)) )))
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> 2 problems remain :
>
> 1- i should be able to change class at runtime.
>
> (corba:defservice ...) => s isa corba:service
>
> (c++-method s) => change class of s. So s isa corba-c++:service and then
> return (c++-method s)
>
> how to do thta and what happens if initially s isa subclass of
> corba:service ? how can i merge the new classes ?
Look up CHANGE-CLASS in the HyperSpec. It seems that it does all you
need, including proper initialization of new slots.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@newsreader2.netcologne.de...
>
> Christophe Turle wrote:
>
> > 2 problems remain :
> >
> > 1- i should be able to change class at runtime.
> >
> > (corba:defservice ...) => s isa corba:service
> >
> > (c++-method s) => change class of s. So s isa corba-c++:service and then
> > return (c++-method s)
> >
> > how to do that and what happens if initially s isa subclass of
> > corba:service ? how can i merge the new classes ?
>
> Look up CHANGE-CLASS in the HyperSpec. It seems that it does all you
> need, including proper initialization of new slots.
>
yes "change-class" & "update-instance-for-different-class" are ok if i only
want to specialize the "corba:service" class.
but 's' could be any sub-class of "corba:service" class. In this case i will
lose all other properties of this sub-class. And finally all i want is to
add a new slot to an instance ! do i really need to change the class of 's',
not sure.
so this should work :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package CLOS-EXT)
(defclass addable-instance-slot ()
( ( addable-slots :reader addable-slots :init-form (make-hash-table :test
#'equal) ) ))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package C++)
(defclass method () ... )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package CORBA)
(defclass service ( clos-ext:addable-instance-slot ) ... )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(in-package CORBA-C++)
(defmethod corba-c++:c++-method ((s corba:service))
(multiple-value-bind (c++-method present)
(gethash "c++-method" (clos-ext:addable-slots s))
(if present
c++-method
(let ((new-c++-method (make-instance 'c++:method :return-type
'c++:void :name "a function of s")))
(setf (gethash "c++-method" (clos-ext:addable-slots s))
new-c++-method) ))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
? (setq s (make-instance 'corba:service ...))
? (corba-c++:c++-method s ) => <c++:method ...>
- not yet tested. But tomorrow with luck & time ...
ctu.
ctu wrote:
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@newsreader2.netcologne.de...
>
>>Christophe Turle wrote:
>>
>>
>>>2 problems remain :
>>>
>>>1- i should be able to change class at runtime.
>>>
>>>(corba:defservice ...) => s isa corba:service
>>>
>>>(c++-method s) => change class of s. So s isa corba-c++:service and then
>>>return (c++-method s)
>>>
>>>how to do that and what happens if initially s isa subclass of
>>>corba:service ? how can i merge the new classes ?
>>
>>Look up CHANGE-CLASS in the HyperSpec. It seems that it does all you
>>need, including proper initialization of new slots.
>>
>
>
> yes "change-class" & "update-instance-for-different-class" are ok if i only
> want to specialize the "corba:service" class.
>
> but 's' could be any sub-class of "corba:service" class. In this case i will
> lose all other properties of this sub-class. And finally all i want is to
> add a new slot to an instance ! do i really need to change the class of 's',
> not sure.
You will recall I said "You lost me, but...". :)
So how much of this slot-adding do you anticipate? Why cannot S just
start with an empty C++-method slot? If many slots are to be added,
well, I am still not worried about efficiency, but: S is created one way
(as an instance of some original class)-- what huge event in its life
requires it to transform itself so dramatically? Perhaps the creation of
S can be deferred until it is know what it is to be.
Anyway, you seem to be having fun, so I won't worry. Stashing it the new
"slot" in a hashtable is kinda OK. An assoc would be more efficient
assuming you are not adding dozens of slots.
For your amusement, there is a package (MCL-only, it seems) called
Capabilities:
http://www.iit.nrc.ca/~martin/capabilities_web/docs/capabilities_home.html
...which allows dynamic addition of superclasses to an instance (which I
now gather is one way you thought to attack this).
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
"Kenny Tilton" <·······@nyc.rr.com> a �crit dans le message de
·····························@twister.nyc.rr.com...
>
>
> ctu wrote:
>
> > "Pascal Costanza" <········@web.de> a �crit dans le message de
> > ·················@newsreader2.netcologne.de...
> >
> >>Christophe Turle wrote:
> >>
> >>
> >>>2 problems remain :
> >>>
> >>>1- i should be able to change class at runtime.
> >>>
> >>>(corba:defservice ...) => s isa corba:service
> >>>
> >>>(c++-method s) => change class of s. So s isa corba-c++:service and
then
> >>>return (c++-method s)
> >>>
> >>>how to do that and what happens if initially s isa subclass of
> >>>corba:service ? how can i merge the new classes ?
> >>
> >>Look up CHANGE-CLASS in the HyperSpec. It seems that it does all you
> >>need, including proper initialization of new slots.
> >>
> >
> >
> > yes "change-class" & "update-instance-for-different-class" are ok if i
only
> > want to specialize the "corba:service" class.
> >
> > but 's' could be any sub-class of "corba:service" class. In this case i
will
> > lose all other properties of this sub-class. And finally all i want is
to
> > add a new slot to an instance ! do i really need to change the class of
's',
> > not sure.
>
> You will recall I said "You lost me, but...". :)
>
> So how much of this slot-adding do you anticipate? Why cannot S just
> start with an empty C++-method slot?
we don't know of the C++-method slot when we design the corba:service class.
> If many slots are to be added,
> well, I am still not worried about efficiency, but: S is created one way
> (as an instance of some original class)-- what huge event in its life
> requires it to transform itself so dramatically?
> Perhaps the creation of S can be deferred until it is know what it is to
be.
Imagine you have a corba service s. in 2003, someone asked you to write the
C++ code of this service. so at this time you can design it with the C++
aspect in mind. imagine now that in 2005, someone ask you to write the Java
code of 's'. It will be great to :
1- add the expertise to write java code from corba:service specification in
your meta-program
2- ask your meta-program to write the java code of s.
so it is not 's' which is changing, but things we do from it.
> Anyway, you seem to be having fun, so I won't worry. Stashing it the new
> "slot" in a hashtable is kinda OK. An assoc would be more efficient
> assuming you are not adding dozens of slots.
ok i keep this hint somewhere in my head. One day it will be cool to express
it declaratively to the meta-program. So it can use it automatically
> For your amusement, there is a package (MCL-only, it seems) called
> Capabilities:
>
> http://www.iit.nrc.ca/~martin/capabilities_web/docs/capabilities_home.html
>
> ...which allows dynamic addition of superclasses to an instance (which I
> now gather is one way you thought to attack this).
i just visited it. It seems to be very close of what i search. But i'm very
confused with the presentation. too many links at start...
ctu.
ctu wrote:
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@newsreader2.netcologne.de...
>>Look up CHANGE-CLASS in the HyperSpec. It seems that it does all you
>>need, including proper initialization of new slots.
>
> yes "change-class" & "update-instance-for-different-class" are ok if i only
> want to specialize the "corba:service" class.
>
> but 's' could be any sub-class of "corba:service" class. In this case i will
> lose all other properties of this sub-class. And finally all i want is to
> add a new slot to an instance ! do i really need to change the class of 's',
> not sure.
Here is another way to achieve this:
(defclass my-mixin ()
(...)) ;; include the new slot here
(change-class
object
(ensure-class
nil
:direct-superclasses
(list 'my-mixin (class-of object)))
This is untested and needs some polishing. And of course, this only
works when you have a MOP at hand.
You could also simply add a slot in the corba:service class that just
takes a property list, and then use that property list to add new
information at run time.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@newsreader2.netcologne.de...
>
>
> ctu wrote:
>
> > "Pascal Costanza" <········@web.de> a �crit dans le message de
> > ·················@newsreader2.netcologne.de...
>
> >>Look up CHANGE-CLASS in the HyperSpec. It seems that it does all you
> >>need, including proper initialization of new slots.
> >
> > yes "change-class" & "update-instance-for-different-class" are ok if i
only
> > want to specialize the "corba:service" class.
> >
> > but 's' could be any sub-class of "corba:service" class. In this case i
will
> > lose all other properties of this sub-class. And finally all i want is
to
> > add a new slot to an instance ! do i really need to change the class of
's',
> > not sure.
>
> Here is another way to achieve this:
>
> (defclass my-mixin ()
> (...)) ;; include the new slot here
>
> (change-class
> object
> (ensure-class
> nil
> :direct-superclasses
> (list 'my-mixin (class-of object)))
>
> This is untested and needs some polishing. And of course, this only
> works when you have a MOP at hand.
>
> You could also simply add a slot in the corba:service class that just
> takes a property list, and then use that property list to add new
> information at run time.
yes !
here are the tests :
? (require "corba-c++")
"corba-c++"
? (setq s (make-instance 'corba:service))
#<Corba:Service #x657238>
? (corba-c++:c++-method s)
#<Method #x6A9058>
? (corba-c++:c++-method s)
#<Method #x6A9058> ;; same returned
? (c++:name *)
"a function of s"
? (c++:return-type **)
C++:VOID
? (setq s (make-instance 'corba:service))
#<Corba:Service #x50B208>
? (corba-c++:c++-method s)
#<Method #x524760> ;; different service so different method
? (corba-c++:c++-method s)
#<Method #x524760>
? (c++:name *)
"a function of s"
? (c++:return-type **)
C++:VOID
and the sources :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; c++.lisp file
(defpackage C++ (:export name return-type syntax void) )
(in-package C++)
(defclass predefined-type ()
( ( syntax :reader syntax :initarg :syntax) ))
(defvar void (make-instance 'predefined-type :syntax "void") )
(defclass method ()
( ( return-type :reader return-type :initarg :return-type )
( name :reader name :initarg :name ) ))
(provide "c++")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; corba.lisp file
(defpackage CORBA (:export service idl-operation))
(in-package CORBA)
(defclass service ()
(( idl-operation :reader idl-operation :initarg :idl-operation ) ))
(provide "corba")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; corba-c++.lisp file
(require "corba")
(require "c++")
(defpackage CORBA-C++ (:export c++-method ))
(in-package CORBA-C++)
(defclass service-mixin ()
(( c++-method :accessor c++-method )) )
(defmethod corba-c++:c++-method ((s corba:service))
(change-class s (cl::ensure-class nil
:direct-superclasses (list (find-class 'service-mixin)
(class-of s))))
(let ((new-c++-method (make-instance 'c++:method :return-type 'c++:void
:name "a function
of s")))
(setf (c++-method s) new-c++-method) ))
(provide "corba-c++")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
need some "polishing" to the dynamic class creation : redundant class
creation should be avoid.
this works with ccl. tomorrow i will check this with cmucl.
ctu.
Christophe Turle wrote:
> (defmethod c++-method ((s corba:service))
> "return the c++ method associated with the corba service"
> (make-instance 'c++:method :return-type 'c++:void) ; where to cache it ?
> )
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> so i want to use :
>
> (in-package APP)
>
> (corba-c++:c++-method s ) ; where s isa corba:service
>
> But each time i call this form, i create a new instance of c++:method.
> So i want to cache it somewhere. a hashtable for this seems redondant
> with the fields of classes.
>
> an idea ?
Declare a slot on corba:service (or on your subclass of corba:service)
with slot-option :allocation :class. That slot option makes CLOS create
one slot that is shared by all instances of the class.
Write c++-method so that if there is a value stored in the class slot,
thee method returns it, but if the slot is unbound the method creates
the c++-method and caches it on the slot. The first time the method is
called it creates the c++-method and caches it; every time it's called
after that, regardless of which instance is the argument, it returns the
cached value from the class slot.
mikel evins wrote:
> Christophe Turle wrote:
>
>> (defmethod c++-method ((s corba:service))
>> "return the c++ method associated with the corba service"
>> (make-instance 'c++:method :return-type 'c++:void) ; where to cache
>> it ?
>> )
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>> so i want to use :
>>
>> (in-package APP)
>>
>> (corba-c++:c++-method s ) ; where s isa corba:service
>>
>> But each time i call this form, i create a new instance of c++:method.
>> So i want to cache it somewhere. a hashtable for this seems redondant
>> with the fields of classes.
>>
>> an idea ?
>
>
> Declare a slot on corba:service (or on your subclass of corba:service)
> with slot-option :allocation :class. That slot option makes CLOS create
> one slot that is shared by all instances of the class.
>
> Write c++-method so that if there is a value stored in the class slot,
> thee method returns it, but if the slot is unbound the method creates
> the c++-method and caches it on the slot. The first time the method is
> called it creates the c++-method and caches it; every time it's called
> after that, regardless of which instance is the argument, it returns the
> cached value from the class slot.
I have ill expressed my problem. I don't want to share a slot. I want to "add" a slot after the class is created. Because the CORBA namespace doesn't know about the "c++-method" requirement.
ctu.