Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: >>> Array(0x1245AB) >>> >>> Personally, I like this format. It's succinct, informative, and tells >>> you enough to do identity testing. >> >> I like it too, but I thought everyone else hated it :) > > I think people like it fine, but many people don't want it to be the > default stringification. Like I said in an earlier thread, the > problem is that there's "stringification for output purposes" and > "stringification for debugging purposes", but we have to chose one or > the other to be the default. I'd rather the debugging one _not_ be > the default, personally, because I imagine the other usage is more > common.
Well, personally I think you're very wrong. Kent Beck is good on this in 'Smalltalk Best Practice Patterns': The two audiences for strings generated by objects, you and your client are often in conflict. You want all the internal, structural details of your object laid out in one place so you don't have to go searching layers and layers of objects to find what you want. Your client assumes the object is working correctly and just wants to see externally relevant aspects of the object in the string. He notes that VisualWorks Smalltalk makes the distinction between 'displayString', for the user oriented stringification and 'printString', for the programmer oriented. Personally I reckon that having the the default behaviour be the 'debugging' string makes too from the point of view of separation of concerns; generally you want to separate formatting from the objects themselves. Also, the debugging approach makes sense from the point of view of a 'composite' object. One can imagine cases where a contained object makes incorrect assumptions about how it is being displayed, which could cause problems for the implementation of the container's as_string method; instead of simply doing: join "\n\t" .members (say), you could find yourself adding class based overrides for different sorts of member objects and it could all get ugly quickly. > An obvious counterproposal would be to say that references are > invisible to stringification (e.g. it stringifies to whatever its > contents stringify to). This would seem to be in keeping with the the > spirit of arrayref/array transparentness, etc. Personally I'm not keen on this idea. The distinction between the thing itself and a pointer to the thing is an important distinction for the programmer to be aware of. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?