On Sat, Aug 12, 2000 at 10:27:17PM -0400, Dan Sugalski wrote:
> At 10:24 PM 8/12/00 -0400, Chaim Frenkel wrote:
> > > "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
> >
> >
> >NW> just deal with filenames universally this would be a big win (leave
> >NW> acls, permissions, versions, etc to s
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:26 PM 8/12/00 -0400, Chaim Frenkel wrote:
>> If we are going to have pre-compiled modules (bytecode or machine) why
>> bother with AUTOLOAD?
>>
>> The "registry" would handle the 'autoloading'
DS> It can't, though. We don't know a
At 10:47 PM 8/12/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> Er, you still have to think about whether something could be tied and
> >> tainted at the same time.
>
>DS> Yeah, that's an issue. We need to hammer out how much is the
>responsibility
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote:
>Dan Sugalski writes:
> > I don't mind if someone overrides the vtable functions for a variable of a
> > built-in type--a standard declaration of:
> >
> > my $foo;
> >
> > is really shorthand for:
> >
> >my generic_scalar $foo;
> >
> > more o
Dan Sugalski writes:
> I don't mind if someone overrides the vtable functions for a variable of a
> built-in type--a standard declaration of:
>
> my $foo;
>
> is really shorthand for:
>
>my generic_scalar $foo;
>
> more or less. If a variable gets its vtable functions messed with, well,
>
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Er, you still have to think about whether something could be tied and
>> tainted at the same time.
DS> Yeah, that's an issue. We need to hammer out how much is the responsibility
DS> of the vtable functions, and how much is the responsib
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> : =item vtable
LW> :
LW> : The vtable field holds a pointer to the vtable for a variable. Each
LW> : variable type has its own vtable, holding pointers to functions for
LW> : the variable. Vtables are shared between variables of the same
L
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> But how do we tell that "I am never going to be inherited by something"
NI> so I can compile this code to use index.
Let try this one. HOw about if we flip the indexing. We assign indices only
to methods that are statically _seen_. I
At 10:26 PM 8/12/00 -0400, Chaim Frenkel wrote:
>If we are going to have pre-compiled modules (bytecode or machine) why
>bother with AUTOLOAD?
>
>The "registry" would handle the 'autoloading'
It can't, though. We don't know at compile time (especially if we're
compiling just a module) what AUTOL
At 10:24 PM 8/12/00 -0400, Chaim Frenkel wrote:
> > "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
>
>
>NW> just deal with filenames universally this would be a big win (leave
>NW> acls, permissions, versions, etc to something else).
>
>The VMS (and TOPS20) advocates will scream here. Versio
If we are going to have pre-compiled modules (bytecode or machine) why
bother with AUTOLOAD?
The "registry" would handle the 'autoloading'
> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes:
DS> On Fri, 11 Aug 2000, David L. Nicol wrote:
DS> [...]
>> Redefining a method during run time --
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> just deal with filenames universally this would be a big win (leave
NW> acls, permissions, versions, etc to something else).
The VMS (and TOPS20) advocates will scream here. Versions are part of
the file name. The default is the latest
At 04:26 PM 8/12/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: This way perl doesn't, for example, have to know how to access an
>: individual element of an array of integers--it just asks the array to
>: return it a particular element. Code MUST use the vtable functions to
>: get or s
At 12:23 PM 8/12/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Yup. It's an issue for things that implement any non-standard semantics for
>: existing ops, especially if those ops are overridden at runtime so the
>: optimizer doesn't know. It's one thing to mess with tied variables, its
>:
At 03:11 PM 8/12/00 -0700, Larry Wall wrote:
>Nick Ing-Simmons writes:
>: Chaim Frenkel <[EMAIL PROTECTED]> writes:
>: >Hmm, will vtbl get rid of all the magic hacks?
>:
>: The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
>: are even called vtables in the sources) to a subse
At 12:14 PM 8/12/00 -0400, Bryan C. Warnock wrote:
>On Fri, 11 Aug 2000, David L. Nicol wrote:
> > Dan Sugalski wrote:
> >
> > > Strong typing and sparse arrays are orthogonal--no reason we
> shouldn't use
> > > them if someone does:
> > >
> > >$foo[time]
> > >
> > > or something of the sort.
[EMAIL PROTECTED] writes:
: This way perl doesn't, for example, have to know how to access an
: individual element of an array of integers--it just asks the array to
: return it a particular element. Code MUST use the vtable functions to
: get or set values from variables. They MUST NOT directly a
> > Splitting apart or putting together either one of these paths is trivial
>
> I think it's far from trivial, especially if you want to take into
> account network names, file versions, protection attributes and ACLs, ...
Access details like this are largely independent of the logical
manipula
Nick Ing-Simmons writes:
: Chaim Frenkel <[EMAIL PROTECTED]> writes:
: >Hmm, will vtbl get rid of all the magic hacks?
:
: The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
: are even called vtables in the sources) to a subset of "values".
Well, yes, but there's a linked l
Nathan Wiger <[EMAIL PROTECTED]> writes:
>$fo = open "C:\Windows\System\IOSUBSYS\RMM.PDR";
>$fo->pathdrive = "C:" ;
I think the drive is "C", not "C:".
>$fo->patharray = [ Windows, System, IOSUBSYS, RMM.PDR ];
I think the patharray is [ Windows, System, IOSUBSYS ].
The file name is
> I think it's far from trivial, especially if you want to take into
> account network names, file versions, protection attributes and ACLs, ...
Sure, this all depends on what we're going to do with this data and at
what level. The biggest problem that modules like CGI.pm have to deal
with is jus
Dan Sugalski writes:
: Yup. It's an issue for things that implement any non-standard semantics for
: existing ops, especially if those ops are overridden at runtime so the
: optimizer doesn't know. It's one thing to mess with tied variables, its
: another entirely to make + behave differently.
Benjamin Stuhl writes:
: --- Bart Schuller <[EMAIL PROTECTED]> wrote:
: > Larry knew what he was doing when he decided on utf8.
:
: It has also led to the perl5 internals being, to put it
: bluntly, a horrible mess. And forget about the regex
: engine.
That's a vast oversimplification. It has v
On Fri, 11 Aug 2000, David L. Nicol wrote:
> Dan Sugalski wrote:
>
> > Strong typing and sparse arrays are orthogonal--no reason we shouldn't use
> > them if someone does:
> >
> >$foo[time]
> >
> > or something of the sort. (People like huge arrays with few scalars in
> > them too... :)
>
David L . Nicol <[EMAIL PROTECTED]> writes:
>
>One assumes that if you redefine (@ISA) perl5 throws away this cache?
Not all at once. It increments a "generation number".
When perl finds it is about to use a cached method it checks to see
if the value post-dates the current generation number, or
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>>> Well, we could preload the vtbl with a _replace_me_ stub to do the
>>> cacheing.
>
>NI> Just leave vtable blank and fill it when we need it - that part of perl's
>NI> mechanism is not the pr
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>NI> If it has to be static then name => index has to be global across all classes
>NI> as ISA tree adds leaves and reconverges.
>
>Run this one by me again. Why isn't it enough to have the inte
27 matches
Mail list logo
