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.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
