John Peacock wrote:
As you might guess, I think you are completely offbase here. Any
class which provides it own overloading for stringification and/or
numification is in the same boat as what the proposed changes for
thread objects. And no special handling is required to handle them,
either. Using the approved methods to interrogate the object is not
that difficult. Violate the sanctity of my opaque objects at your
peril, Sir! ;-)
The fact that the stringification of objects produces (by default) a
unique string in standard format is all I ask. I don't violate your
opaque objects - I just want to be able see immediately (a) the type of
object pointed to by a reference and (b) the unique code for that object.
What you propose is actually a change to the way that references behave
and not the way that your class behaves. That is, you want the behavior
of a reference in certain types of expressions be different depending on
the class of object that it references. That is very different from
overloading a field of a class.
Dumpers need a unique code for the object "pointed to" by a reference.
The current default stringification of objects gives a code that is
unique across ALL objects. If you change that so that the code is
unique WITHIN a class of objects but not ACROSS all objects then any
code that tries to keep track of references using a hash
(i.e.,$objects{$thr}) will have to be broken down into multiple levels
(i.e., $objects{ref{$thr}}{$thr}).
Yes, I can type ref($ref) *EVERY* time I am checking a variable in the
debugger and I can change the dumper to do the same. Just so that you
can get a different hash key? The burden is on you to use $thr->tid()
for your hash key instead of making an incompatible and inconvenient change.
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.
- Jim
