I have recently fixed a problem with method with handles in roles and alongside changed the way the trait is applied. In brief, where previously it was using self."$method_name"()."$delegation()" approach now it invokes the method code object directly. Turns out, the only modules broken by this are CSS and LibXML!
More details are in raku/problem-solving#339. The problem lies in a P6opaque class inheriting from a CPointer and introducing $.raw attribute which overrides the method raw from LibXML::Node, for instance. Where previously delegated method type was invoked on the attribute because its accessor method overrided the parent method, now type goes back to the original raw on LibXML::Node, resulting in an attempt to nativecast into a P6opaque.
For one thing, I don't want to break the backward compatibility, for another – the new approach is less error-prone and allows for some clever tricks.
I have recently fixed a problem with method with
handles
in roles and alongside changed the way the trait is applied. In brief, where previously it was usingself."$method_name"()."$delegation()"
approach now it invokes the method code object directly. Turns out, the only modules broken by this areCSS
andLibXML
!More details are in raku/problem-solving#339. The problem lies in a
P6opaque
class inheriting from aCPointer
and introducing$.raw
attribute which overrides the methodraw
fromLibXML::Node
, for instance. Where previously delegated methodtype
was invoked on the attribute because its accessor method overrided the parent method, nowtype
goes back to the originalraw
onLibXML::Node
, resulting in an attempt to nativecast into aP6opaque
.For one thing, I don't want to break the backward compatibility, for another – the new approach is less error-prone and allows for some clever tricks.