On Fri, Jul 18, 2008 at 8:04 PM, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
> * On Fri, Jul 18 2008, Bill Ward wrote:
>> It occurs to me that if we had the behavior that OO method calling
>> would reject any imported modules, wouldn't that solve the problem?
>
> How do you tell what an imported subroutine is?
>
> There is lots of valid OO code that works exactly like Exporter, namely:
>
> *{ "${caller}::foo" } = sub { ... }
>
> I don't see a way to implement what you want without making Perl
> unusable for modern development. :)
I admit, my suggestion would probably require changes to Perl's
internals, more than what a CPAN module could do. I'm just thinking
that it's bad practice to use Exporter for OO methods, in much the
same way that it's bad to do the other things which "use strict" looks
for. I think that Exporter would probably have to flag the
subroutines somehow to distinguish them from what you show above -- or
we could just say that what you're saying is the equivalent of using
soft references where you have to use "no strict 'refs'" to avoid the
error.
>> I can't think of any reason you would want to use an imported
>> subroutine as an object method
>
> Roles/traits. OO is more than inheritance these days.
With Exporter.pm? I'm still dubious.
> Anyway, I think the conflicting imports can be solved with
> Sub::Exporter. It lets you rename the imports to something useful.
> Obviously not every module on CPAN uses S::Ex, but they should start.
> In the mean time, you can work around with something like:
Never heard of Sub::Exporter. I try to avoid deviations from standard
Perl because it means teaching all the developers new tricks.
