libera/#commonlisp - IRC Chatlog
Search
13:47:59
Josh_2
https://github.com/K1D77A/cl-coinpayments can someone give this a once over and tell me if they see anything wrong? or if they notice anything I can improve?
15:29:04
Josh_2
set-funcallable-instance-function is used to make an instance of an object funcallable right?
15:32:15
beach
What happens (I guess in most implementations) is that you will copy two items from the function you give as an argument to the FUNCALLABLE-STANDARD-OBJECT, namely the entry point and the static environment.
15:33:11
phoe
note that in about 99% cases the function that is set is actually a closure over the object itself, in order to be able to access its slots et al
15:33:12
beach
So the function given as an argument is not stored in the FUNCALLABLE-STANDARD-OBJECT.
15:34:56
phoe
then, unless you run into one of the edge cases I am thinking of, just use a function object then
15:39:45
beach
SICL bootstrapping uses a lot of FUNCALLABLE-STANDARD-OBJECT in the host system, because these objects are both host functions to be executed during bootstrapping by the host, and objects representing target functions with additional slots in them.
16:01:44
beach
And, yes, when the FUNCALLABLE-STANDARD-OBJECT represents a SICL generic function, the instance function is a closure over the FUNCALLABLE-STANDARD-OBJECT, so that the target methods can be accessed in order to construct discriminating functions and such.
16:05:04
Josh_2
No need for that for me as the objects are just being used to represent hooks, no need for them to contain the object themselves
16:07:06
beach
Another piece of information: All SICL function classes are subclasses of FUNCALLABLE-STANDARD-OBJECT. The only reason I can see not to do that are historical, i.e. that the implementation had a FUNCTION class before CLOS was added, perhaps in the form of PCL.
16:08:56
beach
I mean, a function needs to store things like the entry point(s), the static environment, and perhaps debugging information, GC information, etc. Might as well do that as slots of a standard object.
16:11:32
beach
There is obviously a class FUNCTION as required by the MOP, but it is a protocol class.
16:50:56
hhdave
If one has a standard-effective-slot-definition [as returned by class-slots] is there an easy way to see what class it comes from?
16:52:40
hhdave
(other than checking to see if it's one of class-direct-slots for each of the superclasses I suppose)
16:54:38
hhdave
So I guess I have to check if the name of the effective-slot-definition is the direct slots of a class and if not then check all the superclasses and so on?
16:56:30
hhdave
I have an instance and the slot name (obviously). I need to retrieve the slot value from elsewhere, but it's stored according to a DB table that it comes from.
16:57:22
hhdave
I know it could come from several classes - I think I would need to find the most, errr, 'super' one that it comes from and if it comes from a couple of equally high up ones then I think my whole system would break anyway!
16:58:23
hhdave
When I inspect the effective-slot-definition it seems to have a 'class' slot which seems to point to the class that I want, but that doesn't seem to have a method that I know of to access it. I don't know what would happen if I declare the slot in a subclass too.
17:01:52
hhdave
I suppose the only way is to walk up through the superclasses. I just checked the standard effective slot definition of a subclass which redeclares a slot it inherits (adding a type) and the 'class' in the inspector is now the subclass. I think my metaclass would somewhat break in this case anyway. Thanks beach
17:12:05
Bike
you apparently want the direct slot definitions that were merged into that effective definition?
17:12:25
Bike
usually what you do is define your own slot-definition classes, and just put whatever information you need in a slot of the effective slot definition
17:13:10
Bike
you can define a method on compute-effective-slot-definition to define how whatever information you want is merged from the inheritance
17:18:57
hhdave
Bike: ok. Putting the extra info into the slot-definition subclasses might be sensible. I'll get back to it next week. I have subclassed these slot definition classes. Thanks.