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

Reply via email to