On Wed, Aug 20, 2014 at 2:51 AM, Nick Wellnhofer <[email protected]> wrote:
> On 31/07/2014 15:25, Nick Wellnhofer wrote:
>>
>> On 31/07/2014 04:00, Marvin Humphrey wrote:
>>>
>>> It is still important to come up with a general solution to the problem
>>> of autogenerated bindings which do not behave quite right. Our current
>>> hack -- using CFC to autogenerate a "private" helper (i.e. prepended
>>> with an underscore) and then creating a wrapper with the "real" name --
>>> has been revealed as unworkable. However, that hack is still used in
>>> many places -- see much of Lucy.pm and Clownfish.pm.
>>
>> Clownfish.pm seems to be OK. There are no such aliases, only a couple of
>> helper functions that are called from C.
>
> Having a closer look, there are two cases where Clownfish uses Perl
> wrappers: String#Clone and VArray#Clone. But the XSUBs aren't excluded so we
> have both an XSub and a Perl sub. This looks like a bug.
It's an old hack:
# Defeat obscure bugs in the XS auto-generation by redefining clone().
# (Because of how the typemap works for String*,
# the auto-generated methods return UTF-8 Perl scalars rather than
# actual String objects.)
no warnings 'redefine';
sub clone { shift->_clone(@_) }
Without that hack, calling `$clownfish_string->clone` returns a Perl scalar
rather than another Clownfish::String, because cfish_String* is mapped to a
UTF-8 Perl scalar in our clownfish-to-perl data conversion routines.
The reason that we have to redefine the Perl-space method clone() for
Clownfish::String is because Clownfish's XSUB binding generator doesn't offer
per-class granularity -- it's either generate clone() XSUBs for *all*
subclasses of Obj, or none.
Marvin Humphrey
