Why String do not implement #displayString?
Locked
Why String do not implement #displayString?
 
|
Hi.
According to the comment of #displayString it should be used as default textual representation of objects in the UI: But String itself does not respect this message:
Is it bug? Or is there any reason for this? Best regards, Denis |
Re: Why String do not implement #displayString?
|
|
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 |
Re: Why String do not implement #displayString?
|
|
Hi Esteban. 2018-04-10 17:28 GMT+02:00 Esteban A. Maringolo <[hidden email]>: Isn't #displayString implemented in terms of #displayOn: the same way |
Re: Why String do not implement #displayString?
|
|
In reply to this post by Esteban A. Maringolo
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 <[hidden email]> 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 |
Re: Why String do not implement #displayString?
|
|
In reply to this post by Esteban A. Maringolo
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:
-- Esteban A. Maringolo |
Re: Why String do not implement #displayString?
|
|
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 <[hidden email]> 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:
-- Esteban A. Maringolo |
Re: Why String do not implement #displayString?
|
|
In reply to this post by Esteban A. Maringolo
In Object yes (to default to the existing #printOn: implementation), but
there are several other implementors of #displayOn: that work completely different (e.g. Collection, UndefinedObject, etc). Nonetheless, I think the #printOn:/#displayOn: is a good practice, in my Pharo classes I "polyfill" what's missing to support it. Regards! On 10/04/2018 19:42, Benoit St-Jean wrote: > 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) > > > On Tuesday, April 10, 2018, 6:33:05 p.m. EDT, Esteban A. Maringolo > <[hidden email]> 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?). |
Re: Why String do not implement #displayString?
|
|
In reply to this post by Esteban A. Maringolo
Yes I think that
| s | s := 'Hello, ''Funny'' World'. s displayString = s. "true" s printString = s. "false" is ok and widgets should use displayString. Stef On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo <[hidden email]> 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 > |
Re: Why String do not implement #displayString?
|
|
Hi, I am sorry for interrupting this conversation... but | s | s := 'Hello, ''Funny'' World'. s displayString = s "false" and not true! Cheers, Alex On 11 April 2018 at 21:53, Stephane Ducasse <[hidden email]> wrote: Yes I think that |
Re: Why String do not implement #displayString?
|
|
?
On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <[hidden email]> wrote: > Hi, > > I am sorry for interrupting this conversation... but > > | s | > s := 'Hello, ''Funny'' World'. > s displayString = s "false" and not true! > > Cheers, > Alex > > On 11 April 2018 at 21:53, Stephane Ducasse <[hidden email]> wrote: >> >> Yes I think that >> >> | s | >> s := 'Hello, ''Funny'' World'. >> s displayString = s. "true" >> s printString = s. "false" >> >> is ok and widgets should use displayString. >> >> Stef >> >> >> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >> <[hidden email]> 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 >> > >> > |
Re: Why String do not implement #displayString?
|
|
In reply to this post by Aliaksei Syrel
I had to read more carefully :) Yes, it should be true, but now it is false, which is a problem. Cheers, Alex On 11 April 2018 at 22:02, Aliaksei Syrel <[hidden email]> wrote:
|
Re: Why String do not implement #displayString?
|
|
In reply to this post by Stephane Ducasse-3
The point is a list of strings should be displayed as
a b c and not 'a' 'b' 'c' It shows that often people confuse asString and printString BTW. On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse <[hidden email]> wrote: > ? > > > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <[hidden email]> wrote: >> Hi, >> >> I am sorry for interrupting this conversation... but >> >> | s | >> s := 'Hello, ''Funny'' World'. >> s displayString = s "false" and not true! >> >> Cheers, >> Alex >> >> On 11 April 2018 at 21:53, Stephane Ducasse <[hidden email]> wrote: >>> >>> Yes I think that >>> >>> | s | >>> s := 'Hello, ''Funny'' World'. >>> s displayString = s. "true" >>> s printString = s. "false" >>> >>> is ok and widgets should use displayString. >>> >>> Stef >>> >>> >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >>> <[hidden email]> 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 >>> > >>> >> |
Re: Why String do not implement #displayString?
|
|
Ok. I opened the issue 21689 2018-04-11 22:06 GMT+02:00 Stephane Ducasse <[hidden email]>: The point is a list of strings should be displayed as |
Re: Why String do not implement #displayString?
|
|
Thanks denis!
No problem syrel I was also dead tired :) On Thu, Apr 12, 2018 at 10:19 AM, Denis Kudriashov <[hidden email]> wrote: > Ok. I opened the issue 21689 > > 2018-04-11 22:06 GMT+02:00 Stephane Ducasse <[hidden email]>: >> >> The point is a list of strings should be displayed as >> >> a >> b >> c >> >> and not >> >> 'a' >> 'b' >> 'c' >> >> It shows that often people confuse asString and printString BTW. >> >> On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse >> <[hidden email]> wrote: >> > ? >> > >> > >> > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <[hidden email]> >> > wrote: >> >> Hi, >> >> >> >> I am sorry for interrupting this conversation... but >> >> >> >> | s | >> >> s := 'Hello, ''Funny'' World'. >> >> s displayString = s "false" and not true! >> >> >> >> Cheers, >> >> Alex >> >> >> >> On 11 April 2018 at 21:53, Stephane Ducasse <[hidden email]> >> >> wrote: >> >>> >> >>> Yes I think that >> >>> >> >>> | s | >> >>> s := 'Hello, ''Funny'' World'. >> >>> s displayString = s. "true" >> >>> s printString = s. "false" >> >>> >> >>> is ok and widgets should use displayString. >> >>> >> >>> Stef >> >>> >> >>> >> >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >> >>> <[hidden email]> 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 >> >>> > >> >>> >> >> >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |