At 08:44 AM 2/6/01 +, Simon Cozens wrote:
>On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote:
> > Granted, if this was all done with trusted servers it would be really neat,
> > but...
>
>TANSTAATS.
Not even with the appropriate amount of PKI/X.509 hand-waving?
--
Peter Scott
Pac
At 08:44 AM 2/6/2001 +, Simon Cozens wrote:
>On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote:
> > Granted, if this was all done with trusted servers it would be really neat,
> > but...
>
>TANSTAATS.
Cute, but not entirely true. There are an awful lot of servers off the
internet
Simon Cozens wrote:
>
> Whether it's a good idea or a bad idea is largely irrelevant; the
> purpose of -language is to decide whether or not it should be possible.
I think historically this has not been the case.
But I suppose we could change the purpose of -language mid-stream...
--
John Port
On Tue, Feb 06, 2001 at 12:49:28AM +0100, Bart Lateur wrote:
> On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
>
> >> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
> >> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
> >>2 };
> >>
> >>Very good
On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote:
> Granted, if this was all done with trusted servers it would be really neat,
> but...
TANSTAATS.
--
I used to be disgusted, now I find I'm just amused.
-- Elvis Costello
At 07:02 PM 2/5/2001 -0700, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I'm fine with silly things, it's dangerous things I don't much care for.
> > Which isn't to say I'm against loading remote program code, I just think
> > this isn't the way to do it.
>
>use autoload { Bar => 'uddi://bla
Dan Sugalski writes:
> I'm fine with silly things, it's dangerous things I don't much care for.
> Which isn't to say I'm against loading remote program code, I just think
> this isn't the way to do it.
use autoload { Bar => 'uddi://blah/some/Bar' };
(here I take a big swill from the web servic
On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote:
> > > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
> > > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
> >2 };
> >
> >Very good idea indeed!!! Append the wishlist to add this module to perl6's
On Tue, Feb 06, 2001 at 12:49:28AM +0100, Bart Lateur wrote:
> On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
>
> >> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
> >> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
> >>2 };
> >>
> >>Very good
On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
>> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
>> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
>>2 };
>>
>>Very good idea indeed!!! Append the wishlist to add this module to perl6's
>>standard
use autoload { Bar => 'http://www.cpan.org/modules/Bar',
MD5 => boogedyboogedyboogedyboo },
{ Baz => 'ftp://my.local.domain/perl-modules/Baz',
VERSION => 2,
MD5 => dfasgjlkndakjargjbg245098t4lkjng };
Security mechan
Dan Sugalski wrote:
>
> >Regarding #1, if there's no need to make it extensible by users, why
> >have a file at all? This shouldn't change after Perl is built, right?
> >And all of the stuff that's going to be "autoloaded" in this way will be
> >included in the core dist, right? Sounds like some
At 12:54 PM 2/5/2001 -0800, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > > > The parser needs to have it in a standard system-wide place.
> > >
> > >Hmmm. I see what you mean, but why couldn't it be in @INC, first one
> > >wins? The file could be named AutoUse.pm or something.
> >
> > That str
At 09:58 PM 2/5/2001 +, Tim Bunce wrote:
>On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote:
> > At 02:17 PM 2/5/2001 -0200, Branden wrote:
> > > > I think that, if you want this behavior, a module that implements it
> > > > would be just fine. (Why muck with "use"?) To use a modu
On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote:
> At 02:17 PM 2/5/2001 -0200, Branden wrote:
> > > I think that, if you want this behavior, a module that implements it
> > > would be just fine. (Why muck with "use"?) To use a module name
> > > that seems like it could fit this purp
Dan Sugalski wrote:
>
> > > The parser needs to have it in a standard system-wide place.
> >
> >Hmmm. I see what you mean, but why couldn't it be in @INC, first one
> >wins? The file could be named AutoUse.pm or something.
>
> That strikes me as very much too high level a thing. I'm figuring the
At 11:08 AM 2/5/2001 +, David Grove wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 02:17 PM 2/5/2001 -0200, Branden wrote:
> > > > I think that, if you want this behavior, a module that implements
>it
> > > > would be just fine. (Why muck with "use"?) To use a module name
> >
David Grove wrote:
> Please excuse me if I'm not up to date in this thread. I'm going on this
> posting only.
>
> Although I'd agree with you about the security, Dan, this kind of remote
> processing would, I think, be useful in my case as well, although at a
> minimum it should be a non-default o
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 02:17 PM 2/5/2001 -0200, Branden wrote:
> > > I think that, if you want this behavior, a module that implements
it
> > > would be just fine. (Why muck with "use"?) To use a module name
> > > that seems like it could fit this purpose:
> > >
> >
At 02:17 PM 2/5/2001 -0200, Branden wrote:
> > I think that, if you want this behavior, a module that implements it
> > would be just fine. (Why muck with "use"?) To use a module name
> > that seems like it could fit this purpose:
> >
> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' }
Jonathan Scott Duff wrote:
> If the proprietary modules were kept in a CPANish structure, then they
> could just point CPAN.pm at the machine with that structure. CPAN.pm
> could also be modified such that the user gets to tell it where to
> look in detail (e.g., in some directory rather than on
On Mon, Feb 05, 2001 at 09:15:45AM -0200, Branden wrote:
> Well, I think this could be handled by Perl itself. I don't know if there's
> a way of doing it directly with CPAN, but I think it should be independent
> of CPAN, since there could be proprietary modules, that someone would like
> to expo
Branden wrote:
>
> I really would suggest a close look at CORBA's IDL. I don't know if it can
> handle not-objects, as I'm sure it's desired. But I think having CORBA & IDL
> support will be certainly a need in Perl6, as it was stated this was one of
> the objectives behind making strong-typing p
Well, I have two ideas kind of related to this subject, not very directly,
but...
Jarkko Hietaniemi wrote:
> A gut feeling that I have is we can't simply go by interface 'names',
> be they just simple names of funtions/methods or their full 'signatures'
> (let us not even start on (1) how difficu
On Sun, 4 Feb 2001 [EMAIL PROTECTED] wrote:
> > "Dave" == Dave Storrs <[EMAIL PROTECTED]> writes:
>
>
> Dave> When you want to install a new version, you simply prepend it
> Dave> with its version number (or insert it at appropriate place).
>
> Dave> The order is, of course, irrelevant...y
> "Dave" == Dave Storrs <[EMAIL PROTECTED]> writes:
Dave> When you want to install a new version, you simply prepend it
Dave> with its version number (or insert it at appropriate place).
Dave> The order is, of course, irrelevant...you can order it as 1.3,
Dave> 2.0, 1.0 if you want, but the
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> That strikes me as very much too high level a thing. I'm figuring there
DS> will be no more than one file, and we may well go so far as to weld the
DS> processed version of it into a shareable library that gets loaded in as
DS>
At 04:13 PM 2/2/2001 -0800, Nathan Wiger wrote:
>Damian Conway wrote:
> >
> >
> >> Where should this info be maintained? In a module in @INC (sort of
> like
> >> CPAN/MyConfig.pm)? Or in a special file that's only written to via a
> >> module install? Or in a block atop each module th
On Fri, 2 Feb 2001, Garrett Goebel wrote:
> $Foo::VERSION eq 1.00
> |
> | $Foo::VERSION eq 2.00
> | |
> Bar Baz
> \ /
> My::Module
Ideally, it should be perfectly legit to have multiple versions of
a given module on your system, which would resolve this problem nicely.
On Fri, Feb 02, 2001 at 03:07:12PM -0600, Jarkko Hietaniemi wrote:
> > When you come up with a solution to this problem, please send an
> > email to ICANN.
>
> I'm not claiming to have solution: I claim that the com.sun.java.Gorkulator
> isn't one.
Public identifiers.
http://www.docbook.org/tdg/
On Fri, Feb 02, 2001 at 11:56:50AM -0600, Garrett Goebel wrote:
> Michael Schwern's AnyLoader is a bit strange though. To use an explicitly
> qualified function if the only perceivable gain were to allow you to skip
> needing an 'use'. After all, if the purpose is to mangle your namespace...
> why
Damian Conway wrote:
>
> I like that, though I'd go with different key names ("always" isn't
> always, and "tags" is not well related to its effect). How about:
>
>use export implicit => [qw(you get this)],
>explicit => [qw(only by request)],
> comp
> I would assume that 'use' would be done before 'autouse', so any 'use
> lib' statements would already be taken into account? I'm probably
> missing something super-obvious, so please point it out if so.
No. C before C was my assumption too.
> Yeah, a little too tedious. For the
Damian Conway wrote:
>
>
>> Where should this info be maintained? In a module in @INC (sort of like
>> CPAN/MyConfig.pm)? Or in a special file that's only written to via a
>> module install? Or in a block atop each module that's yanked out via
>> MakeMaker? Or???
>
> The parser
> Where should this info be maintained? In a module in @INC (sort of like
> CPAN/MyConfig.pm)? Or in a special file that's only written to via a
> module install? Or in a block atop each module that's yanked out via
> MakeMaker? Or???
The parser needs to have it in a standard system
Damian Conway wrote:
>
> > >However, it also seems that this is getting *really* complicated
> > >really quickly.
> >
> > I'd agree. I was picturing the file the parser used reading
> > something like:
> >
> >socket|Socket|1.0|gt
>
> I think this is the way to go. I'd suggest that the
Instead of saying "needs CGI;" try saying "needs DBI;" and see how it
thinks.
I think it works okay to split the problem into "declares (and does
some work)" and "defines", then maybe override the same set of words to
do this (to keep the degree of difficulty up).
Figure that "core" interfaces a
Dave Rolsky wrote:
>
> That's what I was thinking. The point is that the module identifies the
> services it provides. Multiple modules may provide overlapping sets of
> services. Modules could also be somehow ranked (memory usage and speed
> come to mind).
>
> Then I could put this into my m
> >However, it also seems that this is getting *really* complicated really
> >quickly.
>
> I'd agree. I was picturing the file the parser used reading something like:
>
>socket|Socket|1.0|gt
I think this is the way to go. I'd suggest that the syntax be easier for
humans (
At 02:08 PM 2/2/2001 -0800, Nathan Wiger wrote:
>Dave Rolsky wrote:
> >
> > That's what I was thinking. The point is that the module identifies the
> > services it provides. Multiple modules may provide overlapping sets of
> > services. Modules could also be somehow ranked (memory usage and spe
On Fri, 2 Feb 2001, Jarkko Hietaniemi wrote:
> What I think is needed is some sort of opaque tag: the name of the
> 'contract' the API claims to fulfill. The name can be the name of
> the standard, the name of the company, the name of the individual.
> (Java does a very similar thing but they pr
On Fri, Feb 02, 2001 at 03:07:12PM -0600, Jarkko Hietaniemi wrote:
> I'm not claiming to have solution: I claim that the com.sun.java.Gorkulator
> isn't one.
Hmm. Though, perhaps, Commerce::WebCart::[EMAIL PROTECTED]::v1.0 would be.
I think the Java solution is basicly good, except for a few thi
On Fri, Feb 02, 2001 at 03:54:33PM -0500, John Porter wrote:
> Jarkko Hietaniemi wrote:
> > > I rather like the idea that contract names are themselves namespace
> >
> > I rather dislike it: I think we are trying to stuff to much information
> > on the package namespaces.
>
> Well, I didn't say
Jarkko Hietaniemi wrote:
> > I rather like the idea that contract names are themselves namespace
>
> I rather dislike it: I think we are trying to stuff to much information
> on the package namespaces.
Well, I didn't say *package* namespace; I'm just pointing out that
contract names can probably
> I rather like the idea that contract names are themselves namespace
I rather dislike it: I think we are trying to stuff to much information
on the package namespaces.
> names. A contract version's name is thus defined within that
> contract's namespace.
>
> E.g.
> "specifies Foo::Bar"
From: James Mastros [mailto:[EMAIL PROTECTED]]
>
> Speaking of contract names, is Damien about?
In Class::Contract... the package name is the unique identifier.
Piers Cawley has been working on Interface::Polymorphism
http://search.cpan.org/search?dist=Interface-Polymorphism
Perhaps he has som
Jarkko Hietaniemi wrote:
> A gut feeling that I have is we can't simply go by interface 'names',
> be they just simple names of funtions/methods or their full 'signatures'
>
> What I think is needed is some sort of opaque tag: the name of the
> 'contract' the API claims to fulfill. The name can
> Speaking of contract names, is Damien about?
No, but when you summon the AntiChrist, I sometimes appear instead. ;-)
Damian
On Fri, Feb 02, 2001 at 02:57:20PM -0500, James Mastros wrote:
> On Fri, Feb 02, 2001 at 01:47:29PM -0600, Jarkko Hietaniemi wrote:
> > A DNS name is assuming too much about the organizational
> > structure and a mile long hex digit isn't very friendly, and neither
> > of them is very descriptive.
On Fri, Feb 02, 2001 at 01:47:29PM -0600, Jarkko Hietaniemi wrote:
> A DNS name is assuming too much about the organizational
> structure and a mile long hex digit isn't very friendly, and neither
> of them is very descriptive. "XPG4 SysV IPC" would be. (I just made
> that one up.)
Oh, I quite ag
On Fri, Feb 02, 2001 at 02:36:43PM -0500, James Mastros wrote:
> On Fri, Feb 02, 2001 at 01:17:35PM -0600, Jarkko Hietaniemi wrote:
> > What I think is needed is some sort of opaque tag: the name of the
> > 'contract' the API claims to fulfill. The name can be the name of
> > the standard, the na
On Fri, Feb 02, 2001 at 01:17:35PM -0600, Jarkko Hietaniemi wrote:
> What I think is needed is some sort of opaque tag: the name of the
> 'contract' the API claims to fulfill. The name can be the name of
> the standard, the name of the company, the name of the individual.
> (Java does a very simi
> >I wasn't clear. I was thinking that somehow a module would register with
> >the core what interfaces it support when it is installed. Anything else
> >is madness (ok, my idea is madness too).
>
> Your idea's not madness--it is, in fact, what I'm looking for us to define.
A gut feeling that
At 01:00 PM 2/2/2001 -0600, Dave Rolsky wrote:
>On Thu, 1 Feb 2001, Michael G Schwern wrote:
>
> > Problem is, its extremely difficult to figure out what module
> > implements what. Sure, if you see a C you have a
>
>I wasn't clear. I was thinking that somehow a module would register with
>the c
On Thu, 1 Feb 2001, Michael G Schwern wrote:
> Problem is, its extremely difficult to figure out what module
> implements what. Sure, if you see a C you have a
I wasn't clear. I was thinking that somehow a module would register with
the core what interfaces it support when it is installed. An
John Porter wrote:
> Well, Java has interfaces, but I'm pretty sure that's not
> where we want to go; they're very OO-specific.
And Corba likewise.
--
John Porter
Tim Bunce wrote:
>
> I also think we need to define what an 'interface definition' should
> look like and/or define before we go much further.
Well, Java has interfaces, but I'm pretty sure that's not
where we want to go; they're very OO-specific.
Instead, probably Modula (/Modula3/Oberon) provi
Dan Sugalski wrote:
>
> It's the explicit exporting that I'm concerned about.
> Perhaps I'm being overly worried, but it strikes me that
> if all a module needs to do to get on the autoload list
> is have an @EXPORT_AUTO declaration at the top (or
> something similar) we're going to see it abus
On Fri, Feb 02, 2001 at 11:47:43AM -0500, John Porter wrote:
> And isn't this rather off-topic for this list?
> Sounds more like an internals thing...
No. I think this is an area where the language should lead.
I also think we need to define what an 'interface definition' should
look like and/or
And isn't this rather off-topic for this list?
Sounds more like an internals thing...
--
John Porter
Dan Sugalski wrote:
>
> It's the explicit exporting that I'm concerned about. Perhaps I'm being
> overly worried, but it strikes me that if all a module needs to do to get
> on the autoload list is have an @EXPORT_AUTO declaration at the top (or
> something similar) we're going to see it abuse
At 11:01 AM 2/2/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> >
> > The last
> > thing I want is for every module to automagically export all (or even
> some)
> > of its functions. That way lies namespace pollution *real* fast.
>
>I don't see why this is a concern. Unless some explicit a
Dan Sugalski wrote:
>
> The last
> thing I want is for every module to automagically export all (or even some)
> of its functions. That way lies namespace pollution *real* fast.
I don't see why this is a concern. Unless some explicit arrangement
is made for CGI to export param (following the
At 01:41 PM 2/1/2001 -0500, Michael G Schwern wrote:
>On Thu, Feb 01, 2001 at 12:24:38PM -0600, Dave Rolsky wrote:
> > Here's a gross thought (for implementors at least ;)
> >
> > If it sees
> >
> > use CGI qw( param header );
> >
> > the autoloader could look for a module which implements the 'C
On Thu, Feb 01, 2001 at 12:24:38PM -0600, Dave Rolsky wrote:
> Here's a gross thought (for implementors at least ;)
>
> If it sees
>
> use CGI qw( param header );
>
> the autoloader could look for a module which implements the 'CGI'
> interface and has those two functions.
Problem is, its ext
At 07:34 PM 2/1/2001 -0500, Michael G Schwern wrote:
>On Thu, Feb 01, 2001 at 02:04:41PM -0500, Ken Fox wrote:
> > Dan Sugalski wrote:
> > > Looks pretty close to what's needed. Care to flesh it out (and streamline
> > > it where needed) to a PDD?
> >
> > Isn't the trick to detect the necessary mo
On Thu, Feb 01, 2001 at 02:04:41PM -0500, Ken Fox wrote:
> Dan Sugalski wrote:
> > Looks pretty close to what's needed. Care to flesh it out (and streamline
> > it where needed) to a PDD?
>
> Isn't the trick to detect the necessary modules at compile time?
Yeah, but at least with AnyLoader as a
Dan Sugalski <[EMAIL PROTECTED]> writes:
> The module loaded can define the routines as either regular perl
> subs or opcode functions (the difference is in calling convention
> mainly) [...]
Difference in calling convention at the user level or just internal?
-- Johan
At 09:49 PM 2/1/2001 +0100, Johan Vromans wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > The module loaded can define the routines as either regular perl
> > subs or opcode functions (the difference is in calling convention
> > mainly) [...]
>
>Difference in calling convention at the user
Thus it was written in the epistle of Dave Rolsky,
> On Thu, 1 Feb 2001, Nathan Wiger wrote:
>
> > There's the big problem of overlapping function names. If I say:
> >
> >$name = param('name');
> >
> > I probably mean "use CGI". But maybe there's some other module that has
> > param() also? W
Dan Sugalski wrote:
> At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
> > Have a look at AnyLoader in CPAN.
>
> Looks pretty close to what's needed. Care to flesh it out (and streamline
> it where needed) to a PDD?
Isn't the trick to detect the necessary modules at compile time? Run-time
ca
Dan Sugalski wrote:
> At 02:04 PM 2/1/2001 -0500, Ken Fox wrote:
> >Isn't the trick to detect the necessary modules at compile time?
>
> Nope, no trick at all. The parser will have a list of functions--if it sees
> function X, it loads in module Y. (Possibly version Z) Nothing fancy needs
> to be
At 02:04 PM 2/1/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
> > > Have a look at AnyLoader in CPAN.
> >
> > Looks pretty close to what's needed. Care to flesh it out (and streamline
> > it where needed) to a PDD?
>
>Isn't the trick to de
Ted Ashton wrote:
>
> It appears to me that there's a focus problem here. After all,
> if I want to use CGI or CGI::Minimal, I can already do that.
> The auto-autoloading, unless I am sorely mistaken (which is
> quite possible :-), is for the purpose of moving things out
> of the core and yet a
On Thu, 1 Feb 2001, Nathan Wiger wrote:
> There's the big problem of overlapping function names. If I say:
>
>$name = param('name');
>
> I probably mean "use CGI". But maybe there's some other module that has
> param() also? What if I really mean "use CGI::Minimal"?
Here's a gross thought (f
Dan Sugalski wrote:
>
> At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
> >
> >Have a look at AnyLoader in CPAN.
>
> Looks pretty close to what's needed. Care to flesh it out (and streamline
> it where needed) to a PDD?
There's also autouse, a pragma that ships with Perl. Again, not exactl
At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
>On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> > One of the features of perl 6 is going to be the ability to automatically
> > use a module if one or more preregistered functions are used in your
> > source.
> >
> > Would someo
On Thu, Feb 01, 2001 at 04:02:31PM +, Tim Bunce wrote:
> of the Foo interface (one SX and one pure-perl, for example).
s/SX/XS/ of course.
Tim.
On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> One of the features of perl 6 is going to be the ability to automatically
> use a module if one or more preregistered functions are used in your
> source.
>
> Would someone care to take a shot at formalizing the system? We need a w
On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> The module loaded can define the routines as either regular
> perl subs or opcode functions (the difference is in calling convention
> mainly) and could be the standard mix of perl or compiled code.
>
> Would someone care to take a
On Thu, Feb 01, 2001 at 05:10:55PM +, Tim Bunce wrote:
> On Thu, Feb 01, 2001 at 04:02:31PM +, Tim Bunce wrote:
> > of the Foo interface (one SX and one pure-perl, for example).
> s/SX/XS/ of course.
Dammit. And there was I thinking you'd already designed the extension
system for Perl 6!
On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> Since everyone's spinning aimlessly around, I'll throw out something for
> everyone to think about, and perhaps we can get a PDD out of it.
>
> One of the features of perl 6 is going to be the ability to automatically
> use a modul
At 04:54 PM 2/1/2001 +, Simon Cozens wrote:
>On Thu, Feb 01, 2001 at 11:52:37AM -0500, Dan Sugalski wrote:
> > > just a method for doing what we currently do with, say, glob or
> > >the heavy unicode things?
> >
> > None of the above. What I'm looking for is the pieces that turn the use of
> >
On Thu, Feb 01, 2001 at 04:54:53PM +, Simon Cozens wrote:
> On Thu, Feb 01, 2001 at 11:52:37AM -0500, Dan Sugalski wrote:
> > > just a method for doing what we currently do with, say, glob or
> > >the heavy unicode things?
> >
> > None of the above. What I'm looking for is the pieces that tu
On Thu, Feb 01, 2001 at 11:52:37AM -0500, Dan Sugalski wrote:
> > just a method for doing what we currently do with, say, glob or
> >the heavy unicode things?
>
> None of the above. What I'm looking for is the pieces that turn the use of
> a function into an automagic use of the module containi
At 03:44 PM 2/1/2001 +, Simon Cozens wrote:
>On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
> > The module loaded can define the routines as either regular
> > perl subs or opcode functions (the difference is in calling convention
> > mainly) and could be the standard mix of per
86 matches
Mail list logo
