Re: [RFC] Stringify a thread

--- Jerry Hedden <[email protected]> wrote:

>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");


I'm not sure if I've missed something in the flurry of (heated)
discussion on this topic, but if performance and intuitiveness are
really such a great concern, what's wrong with:

   my $tid = $thr->tid;
   print("Thread $thr started...\n");
   $hash{$thr};

In this case, there is the benefit of _no_ additional performance
overhead of an object method call (e.g. shift->tid()) every time we
need the TID in string form.  And with only one additional, simple
line, we can use the same "convenient" method of using a TID string for
fast hash keys and easily in print statements only if and when we
choose/need to.


Note that I personally don't care much if the behavior changes, given
how relatively minor a change it represents.  But I do question
underlying motives when I see a discussion degrade into statements like
"your very narrow world view is the demand that 'p $thr' in a debugger
print out 'threads=SCALAR(0X0123ABCD)' because you're too lazy to type
'p overload::StrVal($thr)'."

After all, isn't 'overload::StrVal($thr)' more to type (and less
intuitive) than '$thr->tid'?

Last I was aware, maintenance of core perl (source and modules) were
intended to be a community effort for the benefit of the Perl
community, with changes driven by (a majority) consensus within that
community.

And it sounds like a reasonable concensus has been reached: use threads
'stringify';

-Eric