> "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
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
At 05:53 PM 8/11/00 -0500, David L. Nicol wrote:
>Graham Barr wrote:
> > Well perl5 already does that. The first time a method is called it searchs
> > ISA, but it caches the result in the package the object is blessed
> > into, so next time it finds it without searching ISA
>
>
>One assumes that
Graham Barr wrote:
>
> On Thu, Aug 10, 2000 at 06:26:24PM -0400, Chaim Frenkel wrote:
> > > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> >
> > NI> You just re-invented "look up the name in a hash table" ;-)
> >
> > I thought I was saving the constant search along the @ISA, do it onl
> "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 problem.
Aha, we're looking at to differnt dispatc
> "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 integers depend
only on the _current_ @ISA? So it wo
At 04:44 PM 8/11/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> It was a thought, yes.
>
> >> While it would make method lookup faster, it's only benefit over the
> current
> >> method is faster lookup of the first call to a method but at the cost
>
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>I was hoping that the vtbls would be self-operating. Without much need
>to work hard on them.
They would be if you just did not expect so much of them - there is
an intrinsic cost on way Perl method calls work - we can push it about
but eventually ha
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
>GB> The optree needs to know what to perform. an op_call_method needs
>GB> to know which method.
>
>I was hoping that the optree (or whatever) would have a static offset
>into the vtbl.
If it has
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> It was a thought, yes.
>> While it would make method lookup faster, it's only benefit over the current
>> method is faster lookup of the first call to a method but at the cost
>> of extra processing at startup time to cache methods that
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> The optree needs to know what to perform. an op_call_method needs
GB> to know which method.
I was hoping that the optree (or whatever) would have a static offset
into the vtbl.
You seem to think that that's not feasible. If the optree n
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
>>> I thought I was saving the constant search along the @ISA, do it only
>>> once.
>
>GB> Well perl5 already does that. The first time a method is called it searchs
>GB> ISA, but it caches the resul
At 04:51 PM 8/11/00 +0100, Graham Barr wrote:
>On Fri, Aug 11, 2000 at 10:54:43AM -0400, Dan Sugalski wrote:
> > At 03:28 PM 8/11/00 +0100, Graham Barr wrote:
> > >On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> > > > I think we're going to have to have a doubly-linked list going f
On Fri, Aug 11, 2000 at 10:54:43AM -0400, Dan Sugalski wrote:
> At 03:28 PM 8/11/00 +0100, Graham Barr wrote:
> >On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> > > I think we're going to have to have a doubly-linked list going for
> > @ISA, so
> > > when a parent package changes
At 03:28 PM 8/11/00 +0100, Graham Barr wrote:
>On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> > I think we're going to have to have a doubly-linked list going for
> @ISA, so
> > when a parent package changes the child packages get changed too. It'll
> > make updates to @ISA more
On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> I think we're going to have to have a doubly-linked list going for @ISA, so
> when a parent package changes the child packages get changed too. It'll
> make updates to @ISA more expensive, but if you do that then you ought to
> be
At 03:11 PM 8/11/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 06:30:01PM -0400, Chaim Frenkel wrote:
> > Leave a stub behind at the old address that would trigger the repointing.
> > (I'm not clear what to do for refcounting the old address)
>
>That will only work if the sub being defined
On Thu, Aug 10, 2000 at 06:30:01PM -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> GB> On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> >> At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
> >> >You just re-invented "look up the name in a ha
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> I thought I was saving the constant search along the @ISA, do it only
>> once.
GB> Well perl5 already does that. The first time a method is called it searchs
GB> ISA, but it caches the result in the package the object is blessed
GB> into,
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>NI> You just re-invented "look up the name in a hash table" ;-)
>
>I thought I was saving the constant search along the @ISA, do it only
>once.
perl5 does that.
>
>And adding a direct pointer
On Thu, Aug 10, 2000 at 06:26:24PM -0400, Chaim Frenkel wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> You just re-invented "look up the name in a hash table" ;-)
>
> I thought I was saving the constant search along the @ISA, do it only
> once.
Well perl5 already do
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
>> At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
>> >You just re-invented "look up the name in a hash table" ;-)
>> >
>> >You now have one big hash table rather than severa
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> You just re-invented "look up the name in a hash table" ;-)
I thought I was saving the constant search along the @ISA, do it only
once.
And adding a direct pointer for constant methods. ($foo->aMethod).
*sigh*
--
Chaim Frenkel
At 10:00 PM 8/10/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> > At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
> > >You just re-invented "look up the name in a hash table" ;-)
> > >
> > >You now have one big hash table rather than several small
On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
> >You just re-invented "look up the name in a hash table" ;-)
> >
> >You now have one big hash table rather than several small ones.
> >Which _may_ give side benefits - but I doubt i
At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
>You just re-invented "look up the name in a hash table" ;-)
>
>You now have one big hash table rather than several small ones.
>Which _may_ give side benefits - but I doubt it.
If we prefigure a bunch of things (hash values of method names, stor
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>I just realized, that this isn't an original idea. Objective-C does this.
>
>>From what I recall (hmm, must be close to 10 years now) it had the
>same problem in finding the correct c routine to call for any
>selector. Where the selector could be impleme
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>Each sub has a unique number.
(A hash of its name)
>
>Each object would then have a compact representation of only the methods
>that are accessible via method call. (Dynamically generated methods,
>would be added at the end of the vtbl.)
>
>There only
At 08:16 PM 8/10/00 +, Nick Ing-Simmons wrote:
> >The first runtime reassignment of @ISA shoots this one down hard. Sorry.
> >(MI also makes it more difficult, since dependency trees will have to be
> >built...)
>
>Yes - this is why Malcolm dodged MI with 'fields' module.
I'm not sure we can,
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 03:35 PM 8/9/00 -0700, Damien Neil wrote:
>>On Wed, Aug 09, 2000 at 03:32:41PM -0400, Chaim Frenkel wrote:
>>
>>Each sub is assigned an index. This index is unique for the package
>>the sub is in, and all ancestor packages.
Add all sibling packages of
I just realized, that this isn't an original idea. Objective-C does this.
>From what I recall (hmm, must be close to 10 years now) it had the
same problem in finding the correct c routine to call for any
selector. Where the selector could be implemented in a seperate
objecte file.
Anyone on thi
It also fails, with @ISA mutation.
That's why _all_ subroutines would need a unique hash value.
To paraphrase, All problems can be solved with a suitable amount of
indirection.
> "DN" == Damien Neil <[EMAIL PROTECTED]> writes:
DN> In this fashion, the object vtable never needs to contai
> "DN" == Damien Neil <[EMAIL PROTECTED]> writes:
DN> For example:
DN> package Dog;
DN> sub bark { }# Index = 0.
DN> sub bite { }# Index = 1.
DN> The Dog vtable now looks like this:
DN> 0 Dog::bark
DN> 1 Dog::bite
DN> Define a couple of subclass
At 03:35 PM 8/9/00 -0700, Damien Neil wrote:
>On Wed, Aug 09, 2000 at 03:32:41PM -0400, Chaim Frenkel wrote:
> > Each sub has a unique number.
> >
> > Package A - Has nothing blessed, doesn't need the lookup table
> >
> > Package B - Has blessed items, lookup table for all subs that are part
> >
On Wed, Aug 09, 2000 at 03:32:41PM -0400, Chaim Frenkel wrote:
> Each sub has a unique number.
>
> Package A - Has nothing blessed, doesn't need the lookup table
>
> Package B - Has blessed items, lookup table for all subs that are part
> of the package, or in the inheritance tree.
Ar
Graham Barr <[EMAIL PROTECTED]> writes:
>> For the "my Dog $spot" case, that's not an issue, compile time resolution.
>
>And why would an object of type Scotty which inherits from Dog not
>be valid to assign to $spot. And if Scotty overrides some methods
>you have a problem.
We _could_ do the C++
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> Yup. But the vtbl approach allows us to merge op calls and user sub calls
>> into one method.
GB> Ah, you are suggesting something like,
GB> every known sub name is assigned a number and each package has an array
GB> and the op just conta
On Wed, Aug 09, 2000 at 11:53:56AM -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> GB> On Wed, Aug 09, 2000 at 10:01:46AM -0400, Chaim Frenkel wrote:
>
> >> For the "my Dog $spot" case, that's not an issue, compile time resolution.
>
> GB> And why would a
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Wed, Aug 09, 2000 at 10:01:46AM -0400, Chaim Frenkel wrote:
>> For the "my Dog $spot" case, that's not an issue, compile time resolution.
GB> And why would an object of type Scotty which inherits from Dog not
GB> be valid to assign to
At 11:24 AM 8/9/00 -0400, Joshua N Pritikin wrote:
>On Wed, Aug 09, 2000 at 10:16:03AM -0400, [EMAIL PROTECTED] wrote:
> > At 10:01 AM 8/9/00 -0400, Chaim Frenkel wrote:
> > >But for the generic object. The package itself can contain an indirection
> > >table. This would be that sparse table with
On Wed, Aug 09, 2000 at 10:16:03AM -0400, [EMAIL PROTECTED] wrote:
> At 10:01 AM 8/9/00 -0400, Chaim Frenkel wrote:
> >But for the generic object. The package itself can contain an indirection
> >table. This would be that sparse table with the offset in the object vtbl.
>
> That's going to be a v
On Wed, Aug 09, 2000 at 10:01:46AM -0400, Chaim Frenkel wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> So having the object carry around a (pointer to a) table to methods
> NI> has merit. But how to index that table? Computing the union of all possible
> NI> method
At 10:01 AM 8/9/00 -0400, Chaim Frenkel wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>NI> So having the object carry around a (pointer to a) table to methods
>NI> has merit. But how to index that table? Computing the union of all
>possible
>NI> method names for all possib
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> So having the object carry around a (pointer to a) table to methods
NI> has merit. But how to index that table? Computing the union of all possible
NI> method names for all possible classes and assiging each a slot in the table
NI>
46 matches
Mail list logo
