Re: Perl 6's Exporter

2001-12-24 Thread Michael G Schwern
On Mon, Dec 24, 2001 at 04:22:33PM +, Nicholas Clark wrote: > > Also it would cause "subroutine redefined" warnings in this sort of > > code: > > > > use Exporter; > > sub import { > > ... > > Exporter::export_to_level(...); > > } > > Not if it's in EXPORT_OK, sur

Re: Perl 6's Exporter

2001-12-24 Thread Michael G Schwern
On Mon, Dec 24, 2001 at 01:11:21PM +, Nicholas Clark wrote: > > > 4. For modules, saying 'use Exporter' should be enough to get import. > > >If you don't want Exporter's import(), just C. > > > > Very nice. Exporter::Lite does just that. > > What actually stops us retrofitting that onto

Re: Perl 6's Exporter

2001-12-24 Thread Nicholas Clark
On Sat, Dec 22, 2001 at 07:47:31PM -0500, Michael G Schwern wrote: > 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 conflic

Re: Perl 6's Exporter

2001-12-24 Thread Nicholas Clark
On Sun, Dec 23, 2001 at 01:58:32AM -0500, Michael G Schwern wrote: > On Sat, Dec 22, 2001 at 09:20:08PM -0800, Brent Dax wrote: > > I do think that we should get rid of '!symbol' and especially > > '/regex/'; they seem like an unnecessary complication. > > Yeah, chuck 'em. It would be interesti

Re: Perl 6's Exporter

2001-12-22 Thread Michael G Schwern
On Sat, Dec 22, 2001 at 09:20:08PM -0800, Brent Dax wrote: > # 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_

RE: Perl 6's Exporter

2001-12-22 Thread Brent Dax
Michael G Schwern: # 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

Re: Perl 6's Exporter

2001-12-22 Thread Michael G Schwern
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::Dumpe

Re: Perl 6's Exporter

2001-12-22 Thread Uri Guttman
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes: BD> # > 1. Choosing where to export to: BD> # > use Data::Dumper 'Dumper' => 'dumpvar'; BD> # > #exports Data::Dumper::Dumper to Main::dumpvar BD> # (or whatever) BD> # BD> # Where to import to. It'

Re: Perl 6's Exporter

2001-12-22 Thread Bryan C. Warnock
On Saturday 22 December 2001 05:40 am, Brent Dax wrote: > BTW, can we genericize 'use' to work like an indirect-object method? > > use Data::Dumper; > Data::Dumper.use; #same thing Only if you can gel the compile-time semantics of compile-and-run. > # Well, I can't get

RE: Perl 6's Exporter

2001-12-22 Thread Brent Dax
Bryan C. Warnock: # On Saturday 22 December 2001 02:29 am, Brent Dax wrote: # > I've been thinking about improvements that could be made to # Exporter for # > Perl 6. # > # > 1. Choosing where to export to: # > use Data::Dumper 'Dumper' => 'dumpvar'; # > #exports Data::

Re: Perl 6's Exporter

2001-12-22 Thread Bryan C. Warnock
On Saturday 22 December 2001 02:29 am, Brent Dax wrote: > I've been thinking about improvements that could be made to Exporter for > Perl 6. > > 1. Choosing where to export to: > use Data::Dumper 'Dumper' => 'dumpvar'; > #exports Data::Dumper::Dumper to Main::dump