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?
