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
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 idea indeed!!! Append
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 Porter
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 that
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
Pacific
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 difficult
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 a
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' },
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 there
will be
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 purpose:
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 #defines
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 module name
use autoload { Bar = 'http://www.cpan.org/modules/Bar',
MD5 = boogedyboogedyboogedyboo },
{ Baz = 'ftp://my.local.domain/perl-modules/Baz',
VERSION = 2,
MD5 = dfasgjlkndakjargjbg245098t4lkjng };
Security mechanisms
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 library!!!
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 idea indeed!!! Append
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
standard
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 =
"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 then 1.3
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...you can order it
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.
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 that's yanked
"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 part of
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 'CGI'
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 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 arrangement
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 abused
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
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 abused
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) provide
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 Csub foo {...} 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
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 Csub foo {...} you have a
I wasn't clear. I was thinking that somehow a module would register with
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 I have
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 similar
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 name of
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 agree
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.
Speaking of contract names, is Damien about?
No, but when you summon the AntiChrist, I sometimes appear instead. ;-)
Damian
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 be
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 some
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" -- I
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 use
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 *package*
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
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 speed
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 (or at
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
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 needs to
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. Cuse before Cautouse was my assumption too.
Yeah, a little too tedious.
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
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 perl or
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 turn the use
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 containing
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
a function
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 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 way
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 someone care to
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 exactly
right
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 (for
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
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 detect the
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 done.
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
can
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? What if I
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! :)
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 level or
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
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
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 modules at
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 module if
70 matches
Mail list logo
