Front page | perl.perl6.language |
Postings from December 2001
Re: Perl 6's Exporter
Thread Previous
|
Thread Next
From:
Michael G Schwern
Date:
December 22, 2001 16:47
Subject:
Re: Perl 6's Exporter
Message ID:
20011223004731.GR672@blackrider
I've rearranged the proposed features a bit to put the long objections
at the bottom.
Brent Dax wrote:
> I've been thinking about improvements that could be made to Exporter for
> Perl 6.
> 3. Warnings about conflicts:
> use warnings 'Exporter';
> sub Dumper { ... }
> use Data::Dumper qw(Dumper);
> #prints out a warning (not just 'redefined subroutine', either).
This would be nice. In fact, it could be retrofitted onto perl5's
Exporter.
> 4. For modules, saying 'use Exporter' should be enough to get import.
> If you don't want Exporter's import(), just C<use Exporter()>.
Very nice. Exporter::Lite does just that.
> 5. In addition to @EXPORT/@EXPORT_OK/%EXPORT_TAGS, provide a way to do
> it on the 'use Exporter' line.
Getting rid of the @EXPORT* variables entirely would simplify both the
interface and the internals. Exporter could then do a lot more
caching and pre-calculating than it does now since it doesn't have to
worry "Did they alter @EXPORT since the last time import() was
called?"
However, shoving everything onto the use line seems of somewhat
dubious use. For starters, how do you say "don't export import()" and
"export these variables please" at the same time? You start getting
into special "dont_export" flags.
Why not just a regular function or method?
>
> 1. Choosing where to export to:
> use Data::Dumper 'Dumper' => 'dumpvar';
> #exports Data::Dumper::Dumper to Main::dumpvar (or whatever)
>
> 2. Built-in switch handling:
> use Data::Dumper ('Dumper' : qw(+Indent=2 +Useqq));
> #imports Dumper, sets $Data::Dumper::Indent=2, and
> # does $Data::Dumper::Useqq is true
The above are both rare and of dubious practice. But that's not the
real problem I have with it.
What's the biggest problems with Exporter?
1) The man page is Big and Confusing to the first time module author.
2) Exporter is difficult to extend.
3) The internals are twisty and confusing.
And they all stem from one issue:
4) Exporter tries to do too much already.
The two biggest blocks to getting your first modules is figuring out
Makefile.PL (and thus MakeMaker) and figuring out how to export
functions. Both are confusing because the man pages are more
reference than tutorial. They have to be references because the
interfaces are big. The interfaces are big because they try to
implement lots of features. They try to implement every feature
because they're difficult to extend (ie. if you want to add to
Exporter you have to rewrite Exporter). They're difficult to extend
because it wasn't written to be extensible, there's lots of features,
and in Exporter's case, it does backflips to try and be lightweight if
you're only using a subset of its functionality (the Exporter::Heavy
hack).
Its interesting to look at who is using what bits of Exporter. Here's
a very rough breakdown (crude scanner attached, all praise forwarded
to Jeff Friedl).
1271 .pm files scanned
279 using or requiring Exporter
178 using anything beyond @EXPORT and @EXPORT_OK
125 anything beyond @EXPORT, @EXPORT_OK and %EXPORT_TAGS
83 using %EXPORT_TAGS
113 having their own import()
4 using @EXPORT_FAIL
which shows a few interesting things:
1) Exporter isn't being used as much as I'd thought.
2) More people use %EXPORT_TAGS than I'd thought.
3) A lot more people are finding it necessary to write their own
import() routine than I thought.
4) Almost nobody is using @EXPORT_FAIL (its just Carp and Exporter).
So here's the priority list I'd write out for Exporter::NG:
1) Support functionality equivalent to @EXPORT, @EXPORT_OK and
%EXPORT_TAGS and that's it.
2) Make the man page start with a quick tutorial.
3) Make it extensible.
The important thing being that Perl 6's exporter has a small, simple,
easy to explain interface. That it *doesn't* try to shove every
feature into one namespace. And that its easy for people to write
their own exporters.
Then I'd look at those 113 modules that found it necessary to override
Exporter's functionality (I've attached a list) and see what they're
doing. Once you've got a handle on that, move to step four:
4) Write seperate extensions based on the above.
--
Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
This is my sig file. Is it not nify? Worship the sig file.
http://www.sluggy.com
Thread Previous
|
Thread Next