Re: [Pharo-dev] Why String do not implement #displayString?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---

As far as I can remember, yes.  Dolphin has always been like that.
***BUT*** you will also notice that Dolphin has always used #printOn: inside 
#displayOn: ! (Latest image is also like that)


----------------- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

    On Tuesday, April 10, 2018, 6:33:05 p.m. EDT, Esteban A. Maringolo 
<emaring...@gmail.com> wrote:  
 
  
Current VisualWorks (8.x) has #Object>>displayString but it is not implemented 
in terms of #displayOn:
 
Dolphin Smalltalk is the one that has #displayString implemented in terms of 
#displayOn: and uses #displayString in all end user presentations of the 
object, so for aPerson, the inspector would show 'a Person('John Doe')' and on 
a end user ListView the same instance would show 'John Doe'.
 
 
It is like that since Dolphin 5 at least (~2003?).
 
 
Regards,
 
 
 On 10/04/2018 19:04, Benoit St-Jean wrote:
  
  In the "old" days, programmers made sure to respect the following conventions 
: you implement #storeOn:, #displayString: and #printOn: .  Eventually, an 
object will be sent #storeString and #printString and will use your 
#whateverOn: implementation.   
  It looks like that good habit that I've learned at university looooooong ago 
got lost somewhere.  It looks like no one uses #displayString anymore and rely 
solely on #printString instead!  I had a teacher once telling me #displayString 
had a crappy implementation : it just sent #printString and that to be "code 
clean", one should implement  #displayOn: and modify #displayString 
accordingly. 
  But if I recall, VW at the time introduced #displayOn: for widgets and other 
things, hence why #displayString never sent #displayOn:. 
  To make a long story short of what should have been and what it's always 
been, here's an excellent paper on the subject! 
  http://esug.org/data/HistoricalDocuments/TheSmalltalkReport/ST07/04wo.pdf 
  
  ----------------- 
 Benoît St-Jean 
 Yahoo! Messenger: bstjean 
 Twitter: @BenLeChialeux 
 Pinterest: benoitstjean 
 Instagram: Chef_Benito
 IRC: lamneth 
 Blogue: endormitoire.wordpress.com 
 "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)  
  
     On Tuesday, April 10, 2018, 11:28:57 a.m. EDT, Esteban A. Maringolo 
<emaring...@gmail.com> wrote:  
  
   Isn't #displayString implemented in terms of #displayOn: the same way
 #printString is implemented in terms of "printOn:"?
 
 And in the case of String #displayString should return the receiver (it
 is, self), so the following should be true.
 
 | s |
 s := 'Hello, ''Funny'' World'.
 s displayString = s. "true"
 s printString = s. "false"
 
 Regards,
 
 
 On 10/04/2018 12:21, Denis Kudriashov wrote:
 > Hi.
 > 
 > According to the comment of #displayString it should be used as default
 > textual representation of objects in the UI:
 > 
 >    "While printString is about to give a detailled information about an
 >    object, displayString is a message that should return a short
 >    string-based representation to be used by list and related UI
 >    frameworks. By default, simply return printString."
 >    "asString should not be implemented in Object, and kept for
 >    conversion between strings, symbols, text and characters."
 > 
 > But String itself does not respect this message:
 > 
 >    'some string' displayString " ==> '''someString''' "
 > 
 > 
 > Is it bug? Or is there any reason for this?
 > 
 > Best regards,
 > Denis 
 
 -- 
 Esteban A. Maringolo 
 
       
 
 -- 
Esteban A. Maringolo   

--- End Message ---