> "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: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
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 --
On Fri, 11 Aug 2000, David L. Nicol wrote:
[...]
> Redefining a method during run time --- is that even a feature that
> needs to be supported?
I think so. A couple of examples are the Memoize module, which
works by rewriting your memoized function into something that uses
caching, th
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:20 PM 8/11/00 -0500, David L. Nicol wrote:
>> Redefining a method during run time --- is that even a feature that
>> needs to be supported?
DS> Yes.
DS> Also, the problem with vtables holding object methods objects is that
DS> vt
At 02:20 PM 8/11/00 -0500, David L. Nicol wrote:
>Redefining a method during run time --- is that even a feature that
>needs to be supported?
Yes.
Also, the problem with vtables holding object methods objects is that
vtable functions are at fixed, small offsets, while methods are named. This
w
Dan Sugalski wrote:
>
> On Thu, 10 Aug 2000, David L. Nicol wrote:
>
> > Two fields.
> >
>
> This'll cause issues both with GC and thread synchronization. (Besides,
> don't skimp on fields in the base variable structure. Memory's reasonably
> cheap, and shaving a few bytes off isn't worth it an
"Bryan C. Warnock" wrote:
>
> On Thu, 10 Aug 2000, David L. Nicol wrote:
> > Within a perl instance, every object type must register itself on
> > loading. At registration, a number is assigned, the jump table
> > of common functions that that object type overloads is filled, and also
> > a poin
On Thu, 10 Aug 2000, David L. Nicol wrote:
> Two fields.
>
> First is type, which is 0 for a double-precision FP
>
> 1 for a string and higher than that for a defined type in the
> defined type table.
>
> Second is the number, for type 0, and a pointer to
> the beginning of the object for ever
On Thu, 10 Aug 2000, David L. Nicol wrote:
> Within a perl instance, every object type must register itself on
> loading. At registration, a number is assigned, the jump table
> of common functions that that object type overloads is filled, and also
> a pointer to the association for uncommon met
Why not a direct pointer to the vtbl?
And not having a defined type table, one avoids the bookkeeping
overhead of having to register each type. No need to play with
assigning type numbers (no IANA needed.)
Any object can alter its behavior to a non-defined type by simply
creating a vtbl and usin
11 matches
Mail list logo
