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