Re: [RFC] Stringify a thread

Jim Bodwin wrote:
> 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.   

That is *not* the purpose of the default stringification.  However, that 
is exactly what ref() is designed to provide.  There are plenty of 
objects which are opaque collections, not intended to be poked at 
randomly by _any_ code, and which provide overloaded stringification or 
numification, etc (HINT: I've published several of them to CPAN).  Any 
automatic dumper which is relying /exclusively/ on the default 
stringification to elicit any information about the class of an object 
is broken, evil code that should be overwritten with random bytes.

> If this change is made then 
> thread objects will be different from every other object class in the 
> world - and that is a bad thing.  Automatic dumpers and tree walkers 
> will have to add special code for this.

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

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748