Hi John
The tools aren't the ones putting the quotes around the string. Calling
#printString on a String puts the quotes around the string. If you were
to put quotes around other printString's then you would need to special
case String to not put the quotes around twice.
I do not understand your printString point.
to me printString contract is: return a string to represent the receiver
(not talking about self evaluating objects here).
so why when I have
(MFDirectory new name: 'comics') printIt
I do not get why I do not get
'comics' but comics
since printIt invokes printString?
Now I probably broke myself this contract when I introduced
self-evaluating objects.
true printIt
true is probably wrong.
May be printIt is the wrong name.
May be this is displayResult
I do not know there is something confusing.
I'm confuse ;(
The current implementation looks right to me. #printString returns a
string to help developers. #printString on some objects returns a string
that when evaluated creates an equivalent object (e.g., String, Point,
etc.).
I did the self-evaluating behavior and I'm thinking that may be this is
wrong and that
we should always get a string not matter what happens.
However, on other objects it returns a string that only helps the
developer see what the object is (e.g., OrderedCollection). The trick is
to know which object's printString can be evaluated and which are only
for display.
This is where I think that displayString is different than printString and
that
printString no matter what should be consitent
I should return a string and the tools like the repl should display such
as a string.
This is also where
Of course, if you want a string that you can evaluate, you should use
#storeString.
John Brant
--
Using Opera's mail client: http://www.opera.com/mail/
