Re: Specifying vtable API in terms of macros?

2001-02-03 Thread Simon Cozens
On Sat, Feb 03, 2001 at 05:02:27PM +0100, Edwin Steiner wrote: > - This scheme could become a mess, if abused. That's exactly what happened to Perl 5, which your scheme looks strikingly similar to. -- I detest people who get in their cars before turning off the alarm, fiddle around a bit, and

Re: Really auto autoloaded modules

2001-02-03 Thread Uri Guttman
> "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>

Re: Really auto autoloaded modules

2001-02-03 Thread Dan Sugalski
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

Re: Specifying vtable API in terms of macros?

2001-02-03 Thread Dan Sugalski
At 05:02 PM 2/3/2001 +0100, Edwin Steiner wrote: >Might this be madness? (BRAINSTORMS AHEAD!): Generally, yes. :) The vtable stuff won't be exposed outside the core. This means embedding programs and extensions will *not* be using it. Generally speaking, it'll be opcode functions only that'll

Re: Vtables: what do we know so far?

2001-02-03 Thread Dan Sugalski
At 12:21 PM 2/3/2001 +0100, Edwin Steiner wrote: >Matthew Cline wrote: > > > > We might want to have a member/method by which we can tell what type of > > variable we're dealing with, so that a function can be passed an arbitrary > > XV, and treat it differently if it's an SV, AV, and so on. > > >

Re: Vtables: what do we know so far?

2001-02-03 Thread Dan Sugalski
At 10:06 AM 1/31/2001 -0200, Branden wrote: >Matthew Cline wrote: > > Should there be method to tell an SV to change the internal representation >of > > the data? For example, if an SV was created as a string, but is being >turned > > into a float over and over again for use in equations, it woul

RE: Really auto autoloaded modules

2001-02-03 Thread Dave Storrs
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.

Specifying vtable API in terms of macros?

2001-02-03 Thread Edwin Steiner
Might this be madness? (BRAINSTORMS AHEAD!): The API of the Perl data types could be specified in the following way: *) a class hierarchy (hopefully not a deep one). eg. AnyV (XV?) | - | | | | SV

Re: Really auto autoloaded modules

2001-02-03 Thread Simon Cozens
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/

Re: Vtables: what do we know so far?

2001-02-03 Thread Edwin Steiner
Matthew Cline wrote: > > We might want to have a member/method by which we can tell what type of > variable we're dealing with, so that a function can be passed an arbitrary > XV, and treat it differently if it's an SV, AV, and so on. > > For SVs, we might want to have a method to determine what