use warnings;
use strict;

BEGIN {
  print "Before: $_\n" for grep /f/, keys %{main::};
}

sub foo {
  print "I am defined\n";
}

BEGIN {
  print "After: $_\n" for grep /f/, keys %{main::};
}
[download]

Programmers traditionally put their "use" statements near the top of a package. If they do that and put the BEGIN near the bottom, I'm back where I started. Having an arbitrary convention to handle this problem breaks as soon as someone forgets/ignores the convention.

package Trait::Foo;

use strict;
use warnings;

use Some::Other::Module::Which::Exports::Stuff;

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

BEGIN {
  # S:O:M:W:E:S's exported stuff will get picked up
  # here.  That's bad.
}
[download]

Otherwise, you're saying subs first, then BEGIN blocks and then other "use" statements. That basically means telling trait authors to write their traits upside down.

Cheers,
Ovid

New address of my CGI Course.

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).

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.

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