in reply to Re^2: Detecting an imported function (exclude time)
in thread Detecting an imported function

You fetch the list of subs the same way the list of subs is already being fetched. 

package Limit::Traits;

use POSIX ':limits_h';
use Class::Traits ...; # Fetching now will give you "USHRT_MAX" etc.
# but not "foo" nor "bar"

sub foo { ... }
sub bar { ... }

[download]

Later, when Limit::Traits is used, you'll want to export a bunch of subroutines so you fetch the list of all code references in that package again but don't export the ones that were already there when you fetched that same list the first time (in Class::Traits::import).

- tye        

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

    You're arguing for a solution which requires that programmers remember to put their "use" statements in the correct order lest things break, right? So if a programmer forgets and slips in a "use" statement after using "Class::Trait", the code mysteriously breaks in a rather hard to debug way.

    There's no small amount of irony here as one of the rationales of traits is to get around ordering problems of mixins and inheritence heirarchies.

    Cheers,
    Ovid

    New address of my CGI Course.

[reply]
      You're arguing for a solution which requires that programmers remember to put their "use" statements in the correct order lest things break, right?

      Quote:

      Of course, this means that the user needs to 'use' modules that import non-traits before 'use'ing Class::Trait.

      So, "yes".

      So if a programmer forgets and slips in a "use" statement after using "Class::Trait", the code mysteriously breaks in a rather hard to debug way.

      You wanted something implicit and magical. This leads to what you've described above. Make it explicit if you prefer. I, having drunk the Perl kool-aid, would probably allow all three ways to use it:

      1. All subroutines are methods to be 'exported'
      2. All subroutines that were not 'imported' are methods to be 'exported'
      3. Explicitly list which subroutines to 'export'
      4. Explicitly list which subroutines to not 'export'
      5. Explicitly list a dividing line between the two sets
      6. A fanatical devotion to the pope

      All of these have their draw-backs. And most of them have several ways that you could implement them.

      For example, sub :trait foo { ... } is one way to explicitly list which subroutines to 'export'.

      And the way Class::Trait already works involves setting options via use so this all fits together nicely and makes the solution I proposed not so implicit and so no more magical and hard to debug than any of the others (which all involve some action-at-a-distance):

      package Limit::Traits;

use Class::Traits 'base';

use POSIX ':limits_h';            # These aren't trait methods
sub _internal;
use Class::Traits 'export_below'; # or 'export_all' or ...
use Trait::Builder qw( ... );     # These are trait methods

# These, are trait methods:
sub foo { ... }
sub bar { ... }
sub _internal { ... }    # Not a trait method

      [download]

      Pick your poison. Or let your users pick theirs.

      - tye        

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom