slot-boundp-using-class broken in LispWorks 8? about closer-mop

[louis77]

@Hexstream Well, thank you very much for spending 30 seconds to reformat my example code. Greatly appreciated.

[louis77]

Thanks a lot @pcostanza. With your remark I was able to get it working on LispWorks 8. Also, I've submitted a PR to the maintainer of the JZON library.

[pcostanza]

@Hexstream Thanks a lot for pointing this out. You are right in the general case. However, in LispWorks, slot-boundp-using-class and friends actually specialize on the slot name, not the effective slot metaclass. When I created Closer to MOP, I had to decide between making things fully compatible, or alternatively, make them compatible only to the extent that they don't hurt performance. I decided for the latter, and that implies that when you call slot-boundp-using-class and friends in LispWorks directly, you won't get compatible behaviour. However, you can define methods on them specialized on effective slot metaclasses, as specified in AMOP, and you will get the correct semantics. For direct calls, always prefer slot-boundp and friends (without -using-class), and you will be fine.

Again, thanks for pointing this out, I should have explained this better immediately.

[Hexstream]

I haven't looked into this, but

(defclass ping-response () ((message :initarg :message)))

(setf *inst* (make-instance 'ping-response :message "test"))

(setf *class* (class-of *inst*))

(mapcar (lambda (s) (slot-boundp-using-class *class* *inst* s)) (class-slots *class*))

would be better written as

(defclass ping-response ()
  ((message :initarg :message)))

(let* ((instance (make-instance 'ping-response :message "test"))
       (class (class-of instance)))
  (mapcar (lambda (slot)
            (slot-boundp-using-class class instance slot))
          (class-slots class)))

[louis77]

I haven't looked into this, but

@Hexstream
How is that related to the issue?

[Hexstream]

Less unrelated warnings makes it easier to investigate the issue, for one thing.

[pcostanza]

Try this:

(mapcar (lambda (s) (slot-boundp-using-class *class* *inst* s)) (mapcar 'slot-definition-name (class-slots *class*)))

[pcostanza]

It's normally also not a good idea to call slot-boundp-using-class directly. It's a generic function to define methods on, so slot-boundp can call an optimized version if possible. By calling slot-boundp-using-class directly, you might miss cases where the optimization doesn't apply. So better do this:

(mapcar (lambda (s) (slot-boundp *inst* s)) (mapcar 'slot-definition-name (class-slots *class*)))

[Hexstream]

I certainly don't consider myself as big of a MOP expert as @pcostanza, but according to my reading of the (de facto) standard, slot-boundp-using-class absolutely SHOULD accept an effective slot definition as third argument, and SHOULD NOT accept a slot name instead.

I think this ought to be fixed in the MOP implementations and/or closer-mop. (And user code.)

I also think calling slot-boundp-using-class directly is or should be totally legit.
Sometimes it's just convenient, and I don't remember the standard hinting it might not be kosher.

[Hexstream]

Thank you for the quick and comprehensive reply!

The obvious solution here, of course, would be for LispWorks to just fix their MOP implementation. :)

Given their deep technical expertise, I'm rather flabberghasted that they haven't yet bothered to address this trivial issue in nearly 30 years... and I can't even imagine that this kind of change would break much user code, and the fix could be opt-in for a few years.

More generally, I am rather amazed that closer-mop is still needed in 2023.
It should nearly be a no-op by now... (trivial-mop?)