in reply to Re^2: Detecting an imported function
in thread Detecting an imported function

Where do those methods come from?

From the role's package. The current specification, as I understand it, is that anything a role can do, the class doing the role can do.

Is there any chance a role might import a function (even as a constant) and have it exported?

If Role->can('foo'), then Class->does('Role') implies Class->can('foo') for all foo in Role. If this isn't the spec, then I can provide a mechanism in Perl6::Roles that will account for that. Let say you define a "@ROLE_METH" or somesuch. But, the current P6 spec, as I understand it, says that the class will get everything.

There is some discussion on p6l about whether or not the role will be able to reserve methods that are labelled private/protected/other, but, AFAIK, @Larry hasn't made a decision one way or the other.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^4: Detecting an imported function
by Ovid (Cardinal) on Nov 17, 2005 at 16:27 UTC

    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")
+--------+

    [download]

    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.

[reply]
[d/l]
      When I wrote Perl6::Roles, stvn and I talked through this issue, along with chromatic, Luke, and Tim. The P6 spec says a few things:
      • If a class provides a method, then the corresponding method in the role will be ignored.
      • If an instance does a role on its own, then the role's methods will silently override the methods that the class would provide.

      More importantly, it currently says nothing on whether a role exposes an interface or if it is, itself, the interface. Please bring that up on P6l if that's a problem for you. Right now, P6 roles export EVERTHING, including methods, subs, and the like.

      I briefly thought about providing an optional mechanism by which you can specify in the role what it actually exports. I didn't implement it because that wasn't one of Tim's requirements and I was writing this for him to use in DBIv2. However, if that is one of your requirements, I can easily add it in less than 20 minutes. Please specify if you want to use an array a la Exporter or if you want to use attributes.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

        So, on my wishlist:

        1. Only export methods this the trait promises to provide
        2. Conflict resolution via method renaming
        3. Conflict resolution via denying a method (so another trait can provide it)
        4. Trait requirements must be explicitly met or we fail at compile time
        5. Properly respecting the above traits even when aggregating traits into a new trait

        With the exception of the first item on that list, Class::Trait handles this. Does Perl6::Roles handle these? If so, I'll consider a switch.

        Cheers,
        Ovid

        New address of my CGI Course.

[reply]

In Section Seekers of Perl Wisdom