Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

import collisions

2 views
Skip to first unread message

Jonathan Lang

unread,
Oct 5, 2006, 4:11:24 PM10/5/06
to perl6language,
What if I import two modules, both of which export a 'foo' method?

IMHO, it would be nice if this sort of situation was resolved in a
manner similar to how role composition occurs: call such a conflict a
fatal error, and provide an easy technique for eliminating such
conflicts. One such technique would be to allow the import list to
rename items by means of Pairs: any Pair that occurs in the import
list uses its key as the item's old name and its value as the new
name. Thus,

use Foo (foo => 'bar');
use Bar (:foo<baz>);

would import 'foo' from 'Foo', but it would appear in the current
lexical scope as 'bar'. Likewise, it would import 'foo' from Bar, but
would rename it as 'baz'.

Another possibility would be to supply a substitution rule that
transforms the names.

--
Jonathan "Dataweaver" Lang

Aaron Sherman

unread,
Oct 5, 2006, 4:56:44 PM10/5/06
to Jonathan Lang, perl6language,
Jonathan Lang wrote:
> What if I import two modules, both of which export a 'foo' method?

That's always fine unless they have exactly the same signature. In
general, that's not going to happen because the first parameter is
created from the invocant. Thus:

use HTML4;
use Math::BigFloat;

should give me a:

# A divide-by-string form. Who knows why.
our Math::BigFloat multi method div(Math::BigFloat $self:
Str $divisor) is export {...}
# Generate an HTML block that contains self + new content
our HTML4 multi method div(HTML4 $self: Str $more)
is export {...}

When exported these do not conflict. Only plain multis would conflict:

module A;
our Str multi foo(Str $x) is export {...}
module B;
our Str multi foo(Str $x) is export {...}

> IMHO, it would be nice if this sort of situation was resolved in a
> manner similar to how role composition occurs: call such a conflict a
> fatal error, and provide an easy technique for eliminating such
> conflicts.

I think that should probably be a warning under "use warnings", and
otherwise ignored. You asked for the modules in a particular order, and
that's the way they were merged. Overlaps are bound to happen sometimes.

> use Foo (foo => 'bar');
> use Bar (:foo<baz>);

That's an advisory, of course, requesting that aliases be created, but
how much work that does depends on how many signatures are defined for
each name. You could still call Foo::foo, of course, but yeah, this
makes fine sense.

0 new messages