Nick Wellnhofer wrote on 7/28/14 7:12 PM: > Lucifers, > > 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?
I tend to agree with Marvin on this. If I spelunk the code and find a method I want to override, and then can't figure out why Perl never calls it but C does, I will tear what little hair I have left out trying to debug. POLS. It's not unusual IME to have a superclass with private methods that are reserved to the superclass. Often those methods have some kind of naming convention that is documented, even if the methods themselves are undocumented, so that users who extend the class know to stay clear of such names. Example: Clownfish reserves private function and method names with the [[whatever]] prefix, so avoid those names in your subclass method names. That's usually sufficient, IMO, as a caveat. Even if we didn't/don't have naming prefix conventions, I would keep the existing behavior of croaking if someone does hit on a name. That would be a clear message that the name is reserved and to pick a different one. -- Peter Karman . http://peknet.com/ . [email protected]
