For Perl 6, this is not unreasonable as it's rather easy to disambiguate methods and subroutines. That's not so easy in Perl 5. Instead, consider the example in my root node. I have traits which import functions such as "encode_entities". That's not a method and shouln't be exported by the role. Further, having those things accidentally exported is an encapsulation violation. My classes using roles should not have to worry about what tools those roles use to accomplish their tasks.
However, that's not the only problem I have here. Right now it's cluttering my namespace but having avoided a bug is only a matter of chance. For example, we have a base class called "Mammal" which provides an "eat" method. It's subclassed by "human" of which we have an instance which "does girlfriend":
+--------+ | Mammal | (provides "&eat") +--------+ | V +--------+ | Human | (does "girlfriend") +--------+
Now imagine that the girlfriend trait imports a function to read files and that function is called "eat". If that's exported to human, there's no conflict because the human doesn't implement "eat" directly. However, we've now silently overridden the inherited "eat" method. The code breaks, there's no hint that it's going to. Everything's bad.
Needless to say, blindly exporting every function causes problems worse than my skills at analogy.
Cheers,
Ovid
New address of my CGI Course.
In reply to Re^4: Detecting an imported function
by Ovid
in thread Detecting an imported function
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |