On Mon, Jul 28, 2014 at 4:12 PM, Nick Wellnhofer <[email protected]> wrote: > I’d like to discuss how to handle the case when a Perl class defines a > method with the same name as a Clownfish method that is excluded from the > bindings (manually or because the return type or parameters can’t be > mapped). The current code throws an exception. This might be confusing if a > user defines such a method in a subclass without even knowing that the same > name is used by Clownfish under the hood. > > I think the better approach would be to let Clownfish simply ignore such > methods. They would work only in Perl-space and never be called from > Clownfish. Since they’re not part of the Perl API, this shouldn’t cause > problems. What do you think?
Hmm, this would mean that an object can have two distinct methods with the same name which get invoked in different contexts: in C-space, one method gets called, while in Perl-space, another one gets called. I feel like that makes it harder to reason about the class -- when you talk about calling "do_stuff" on an object, which "do_stuff" are you referring to? It wouldn't be confusing to have two different methods for different contexts if they were conspicuously scope-limited by a `private` qualifier or something similar. But instead what differentiates these methods from other methods might be quite subtle: returning `char*`, or accepting an argument of type `void*`. Another item worth noting is that the proposed behavior change optimizes for a different failure mode. The current behavior protects inquisitive hackers attempting to override a method they "shouldn't" know about from silent failure. The proposed change protects innocents who don't know about a hidden method from noisy failure. Can you provide a concrete example? Marvin Humphrey
