Re: [RFC] Stringify a thread

Jim Bodwin wrote:

NOTE: I am not the author of threads, but am just an interested party.

> 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.

You have a very narrow, and I might say a little bizarre, interpretation 
of how Perl objects stringify.  Overloading and objects are two largely 
independent issues; you can have objects which don't use overloading at 
all.  Those objects will obviously fall prey to the default 
stringification.  However, object classes are completely free to create 
their own overloading behavior (see below).  If you are relying on all 
objects to provide you with the default stringification, which was *not* 
intended to be a mandatory feature of objects, merely a convenience 
function, then your code *will* break, and I'm not the least bit 
sorry... ;-)

> 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.

Yes, overloading allows me, as a class author, full freedom to decide 
how my object will behave in different situations.  It has nothing 
whatsoever to do with the behavior of well-behaved introspection tools:

$ perl -Mversion -MData::Dumper -e '$vobj = qv("1.2.3");
print Data::Dumper->Dump([$vobj],['vobj']);'
$vobj = bless( {
                  'qv' => 1,
                  'version' => [
                                 1,
                                 2,
                                 3
                               ]
                }, 'version' );

Here you can see that ref($vobj) would return 'version' as the class, 
yet the introspection code can still understand that the underlying 
object representation is a hash of scalars and arrays.

What code do you have that can't handle this?  Or are you just arguing 
the theoretical case?

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