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
[EMAIL PROTECTED] wrote:
John Porter wrote:
we would only implement changes that add something desirable.
How does removing time() add something desirable?
I'm not motivated to give an answer to that, because
I'm not arguing in favor of removing time().
--
John Porter
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
David L. Nicol wrote:
I recalled hearing about a language where
you set the return value of a function by
assigning to the name of the function within the function body,
Fortran and Pascal do that. Maybe others.
It would mean that
sub subname(proto){
# in here,
David L. Nicol wrote:
To answer my own question, the thing I found annoying about the syntax
when it was shown to me was that it seemed to break portability: you can't
cut from a function called A that returns something by assigning to A and
paste into a function called B to get the same
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 08:09:36AM -0500, Charles Lane wrote:
Peter Scott [EMAIL PROTECTED] wrote:
At 07:12 PM 2/1/01 -0600, David L. Nicol wrote:
I recalled hearing about a language (was it java?) where
you set the return value of a function (was it VB?) by
assigning to the name of the
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
On Thu, Feb 01, 2001 at 07:12:31PM -0600, David L. Nicol wrote:
Looking over some C code of the form
int fname(char *param){
int rval;
...
return(rval);
}
I recalled hearing about a language (was it java?) where
you set the return value of a function (was
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
33 matches
Mail list logo
