Re: [RFC] Stringify a thread

On approximately 10/5/2006 12:42 PM, came the following characters from 
the keyboard of Jerry Hedden:
> Jim Bodwin wrote:
>   
>> I *STILL* haven't heard a reason why you want the hash key
>> to be a number instead of a string with the word "thread"
>> in it.  You should not know or care what the hash key is
>> as long as $thr gives you a unique result.
>>     
>
> 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.)
>
> 3. Suscinctness - $hash{$thr} as opposed to $hash{$thr->tid}.
>
> 4. Intuitiveness - print("Thread $thr started...\n");
>
>   
>> On further thought, I'll claim that putting the following to
>> overload stringification for a class:
>>    '""' => \&tid
>> should affect the behavior of $$ref and not $ref.
>>     
>
> No.  $$ref is scalar dereferencing, and is handled by '${}'.
>
>   
>> The current behaviour (where stringifying a thread returns
>> the class name plus addrress) *IS* used by automatic
>> dumpers.   It is also a handy feature in interactive
>> debuggers since you can immediately tell what kind of
>> object a pointer is pointing too.
>>     
>
> The purpose of overloading is to add value to the class, and
> hence make it more useful in code.  While it may, at times,
> confound simplistic debugging, that issue is secondary to
> the benefits of overloading.  If it were the other way
> around, then overloading would be forbidden.
>   
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.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking