Re: [RFC] Stringify a thread

[email protected] ("Joshua ben Jore") Thu, 5 Oct 2006 16:07:10 -0500
Newsgroups perl.perl5.porters,perl.ithreads
Message-ID <[email protected]>
On 10/5/06, Glenn Linderman <[email protected]> wrote:
> On approximately 10/5/2006 12:42 PM, came the following characters from
> the keyboard of Jerry Hedden:
> > Okay, how about 4 reasons why stringification of threads
> > objects is better:
> >
> > 1. Speed - retrieving the TID is faster than generating a
> > 'threads=SCALAR(0x100110ec)' string.
> >
> > 2. More speed - the shorter the hash key the faster the
> > lookup.  (Yes, I've tested this.  The more characters in the
> > key, the more cycles it takes to compute the hash for that
> > key.)

For Jerry,
I'm asking you to choose. Objects that stringify to something that
looks like a number sucks in the general case. I suppose there are
specific cases where this is great but it's not unalloyed
wonderfulness.

Anyway, why are you using overloading if you care about speed? I never
bench marked it myself to see the difference but I've gotten the
impression that just having this present in the class makes doing
anything with the object slower. For sure I've noticed a whole heap of
additional ISA walking when I've instrumented that on overloverloaded
objects.

> > 3. Suscinctness - $hash{$thr} as opposed to $hash{$thr->tid}.
> >
> > 4. Intuitiveness - print("Thread $thr started...\n");

Bah. This is anti-intutive. To me anyway.

For Jim,

> Agreed.  Personally, I sympathize with the effort to make the
> stringification more useful, but concur that backwards compatibility
> should be kept for Perls with version < 5.9, unless some extra import
> rule or API call is made to convert to the new stringification.
>
> Regarding debuggers and dumpers, once stringification occurs, is there a
> standard method or technique available to obtain a string equivalent to
> the default stringification?  If not, should there be?
> UNIVERSAL->default_stringification? Then an updated debugger/dumper
> could obtain that value, and use or display it in places where it is
> useful or requested.

This is already called overload::StrVal( ... ). You might do this: C<<
overload::Overloaded( $obj ) ? overload::StrVal( $obj ) : "$obj" >> if
you were being especially sane about attempting to avoid calling the
object's overloading and wanted to get back "the default."

Josh