On Tue, Sep 19, 2000 at 07:17:20PM -0700, Nathan Wiger wrote:
> > ==================================================================
> > Either way I'm not sure it solves the problem; if each module asserts
> > that *they* are the smarter one then you either wind up with the same
> > situation you have now or even worse contention.
> > ==================================================================
> >
> > Yes. So do not do this.
>
> My concern was not if you have control over both modules, but what if
> you don't?
> Then you need a way to say ":override_the_override". But then you're
> back at square one.
Do you mean the situation when
a) Module A assumes that it is smarter than B;
b) Then some time passes, and B becomes smarter than A;
I assume your question is: how would B inform the world about this?
My solution is simple: in the situation you describe the module A is
buggy. This is of no concern to Perl.
As I said, the "override" declaration should be done either by
modules, or by users. The in-module override should be based on the
*semantic*, not on the current state of art. Say, BigFloat may
override BigInt in either (or both) BigInt.pm and BigFloat.pm.
All the other override declarations should be done by users.
> Python has a neat method called C<__radd__> which acts when it's the
> right argument in +, and to my understanding allows two classes to
> interoperate in some situations. You might want to check it out if
> you're not familiar with it:
>
> http://www.python.org/doc/2.0b1/ref/numeric-types.html
Lookup in this page shows that the semantic is exactly the same as in
current version of Perl overloading.
These functions are only called if the
left operand does not support the corresponding operation.
> Finally, rather than being implemented in terms of single ":override"
> tag, I think a better way might be to attach attributes to the special
> subs:
>
> sub ADD : override('Math::BigInt') { }
> sub DIV { }
> sub MUL : override(__ALL__) { }
>
> Because you may not want to override all operations for a class.
I consider this to be too fine a control to be useful. Remember that
you can always check the type of the other argument inside your
addition-handler.
Ilya
