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
Filipe Brandenburger wrote:
[...]
> struct sv {
> vtable_sv * ptr_to_vtable;
> void * ptr_to_data;
> void * gc_data;
> };
[...]
> I don't think I can get further from here. Note that, in all examples,
> I didn't write the `this' pointer that every funct
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 function within the function body,
>>so the last line would be
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
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 a
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
And isn't this rather off-topic for this list?
Sounds more like an internals thing...
--
John Porter
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
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
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 abus
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
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
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
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
> >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
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 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 nam
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
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: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
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
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
> 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
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
> 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"
Edwin Steiner <[EMAIL PROTECTED]> writes:
>Filipe Brandenburger wrote:
>[...]
>> struct sv {
>> vtable_sv * ptr_to_vtable;
>> void * ptr_to_data;
>> void * gc_data;
>> };
>[...]
>> I don't think I can get further from here. Note that, in all examples,
>
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, 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
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
> > make $__ mean "An alias for the
> > L-value of what the subroutine return value will get assigned to, or
> > ${undef} if we're not invoked as an R-value."
> A /much/ better syntax, in [John Mastros's] humble opinion. However,
> $__ must act sanely when we're called as an inner function (IE
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
> >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 (
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
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
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 f
> 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:
>
>
>> 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
> 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:
>
> 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
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
On Fri, Feb 02, 2001 at 05:01:29PM -0600, David L. Nicol wrote:
> > A /much/ better syntax, in [John Mastros's] humble opinion. However,
"James", BTW. (No, I don't really care.)
> > $__ must act sanely when we're called as an inner function (IE foo(bar(42))).
> if we allow $__ to have meaning mo
45 matches
Mail list logo
