Front page | perl.perl5.porters |
Postings from February 2009
Re: method names clash by importing: next step
Thread Previous
|
Thread Next
From:
Dmitry Karasik
Date:
February 25, 2009 11:44
Subject:
Re: method names clash by importing: next step
Message ID:
84skm2l2sj.fsf@tetsuo.karasik.eu.org
Hi Rafael!
On 25 фев 09 at 12:46, "Rafael" (Rafael Garcia-Suarez) wrote:
Rafael> 2009/2/25 Dmitry Karasik <dmitry@karasik.eu.org>:
>> A new extension mro::method_import(PACKAGE,BOOLEAN) switches between
>> the existing and new modes, further called import and non-import. The
>> modes are per-package, and govern method resolution order when the
>> package inherits from another packages and simultaneously imports
>> names. The existing import mode overloads the methods with imported
>> names. The non-import mode doesn't, except when the imported names were
>> declared with :method attribute.
Rafael> I still find this too complicated. I feel that Perl should be
Rafael> simpler.
I should agree, albeit reluctantly. My proposal tries to minimise
backward incompatibility, but at the expense of complication.
I wish I could see a solution that is both backward compatible
and less complex, but I can't. Possibly we should drop backward
compatibility constraint, but I personally wouldn't propose that.
Rafael> Currently Perl doesn't have methods. Well, there is a mostly
Rafael> unused :method attribute, and that's all. Here's what it does,
Rafael> from attributes.pm :
Rafael> =item method
Rafael> Indicates that the referenced subroutine is a method. This has
Rafael> a meaning when taken together with the B<locked> attribute, as
Rafael> described there. It also means that a subroutine so marked will
Rafael> not trigger the "Ambiguous call resolved as CORE::%s" warning.
Rafael> How to take advantage of this to solve our language design
Rafael> problem? To get back to the original problem, we don't want to
Rafael> hide methods by importing subroutines. This can be done in two
Rafael> ways, 1. tell perl to be clever (your proposal), and that will
Rafael> help at run time only, or, 2. tell the user to be more clever
Rafael> (i.e. emit yet another warning), which will help at compile time
Rafael> only. (We could do both, too.)
Indeed, we could do both.
Rafael> So we could just say that a method declared with :method will not
Rafael> be clobberred by an imported non-method. That would probably be
Rafael> simpler to implement too. Maybe just a warning is enough here,
Rafael> then ?
Rafael> What do you think ?
I see that your proposal is a sort of an inverse from mine, where yours
promises the correct behavior for :method subs only, and mine tries
to do the right thing for all subs. I like it too, bit I must point
to a scenario in the future when the feature becomes implemented and popular,
and so everyone starts changing the old code by appending :method to
thousands of subs. I think that in order to be adopted, a much less
amount of change should be expected (this was also my unstated goal).
As I said, I hoped that base.pm or parent.pm would turn on the new
feature by default, so the legacy code that inherits with @ISA and Exporter
wouldn't be affected. From that point of view, Zefram's proposition
about methods.pm is still better, since the amount
of code change is minimal. OTOH my approach, if it becomes default,
suffers from cases where one deliberately wants to import methods,
as you pointed with mixins, and as Stevan Little pointed on perlmonks:
he imports Scalar::Utils::blessed for $obj->blessed magic. I can't say
that my approach doesn't bring trouble here (except of course if it is
off by default, but then again, that becomes too complex).
Another problem I can't think of how to solve with :methods being
non-overridable by imported methods. Consider cases where we want
to design a class that imports some names, but we want to make sure
that whatever we import wouldn't backfire. In other words, I'd like
to have an utility to make imports stay local to the package no matter
how the parent classes were implemented, with or without :method.
I'd also like to have an utility to make imports behave as mixins.
And I don't know how to make this happen with the importing mechanism we
have now.
--
Sincerely,
Dmitry Karasik
Thread Previous
|
Thread Next