Hi,
I think Martin makes a very good point about the various *String messages. Should we aim for that in >4.5? Best -Tobias Begin forwarded message: > From: Martin McClure <[hidden email]> > Subject: Re: [Pharo-dev] [Glass] printString and asString > Date: 3. Januar 2014 20:55:20 MEZ > To: Otto Behrens <[hidden email]> > Cc: Discusses Development of Pharo <[hidden email]> > Reply-To: Pharo Development List <[hidden email]> > > On 01/03/2014 12:33 AM, Otto Behrens wrote: >> Hi, >> >> I've run into one of my favorite problems in Smalltalk and decided to >> try the list. Please don't shoot me on this one; perhaps you've run >> into it yourself. If there are discussions that I should read, please >> send me some info. > > Hi Otto, > > Well, you asked for comments. This is my personal opinion, which varies > quite a bit from most implementations, since it's a bit 'old-school > Smalltalk'. But I think the scheme below does fairly neatly distinguish > the purposes of the various messages, which have gotten muddied over the > years as new developers use the language somewhat differently. But maybe > it was never the way I think I remember it being. :-) > > > #printString and #printOn: > These should answer a human-readable description of the receiver. The > description does not need to include the class name, though it can. All > objects should respond to these messages. Generally, #printString should > be implemented in terms of #printOn: -- if you're writing to a stream > you may not want to pay the cost of creating an extra string. > #printString is the equivalent of other languages' toString(). > > #asString > There should not be an Object>>asString. This message is *only* for > converting string-like things to actual strings. So it would be > implemented in String (to return self) and in Symbol, and *maybe* in > things like ByteArray (where it does not *describe* the byte array, but > answers a string whose characters have the values of the bytes). > > #storeString > Produces legal Smalltalk source code that when executed will produce an > equivalent object to the receiver. Needs to be implemented only for > objects that can be specified as literals in Smalltalk syntax, but could > probably be implemented for a few other simple objects. > > #displayString and so on. > UI frameworks and applications will need to have their own ways of > textually representing objects, so will add their own messages such as > #displayString. The *only* messages that any application or framework > can depend on *all* objects responding to are those that it defines > itself, and #printString and #printOn:. > > Regards, > > -Martin > signature.asc (1K) Download Attachment |
On 3 January 2014 20:08, Tobias Pape <[hidden email]> wrote:
> Hi, > > I think Martin makes a very good point about > the various *String messages. > Should we aim for that in >4.5? Yes :) frank > Best > -Tobias > > > Begin forwarded message: > >> From: Martin McClure <[hidden email]> >> Subject: Re: [Pharo-dev] [Glass] printString and asString >> Date: 3. Januar 2014 20:55:20 MEZ >> To: Otto Behrens <[hidden email]> >> Cc: Discusses Development of Pharo <[hidden email]> >> Reply-To: Pharo Development List <[hidden email]> >> >> On 01/03/2014 12:33 AM, Otto Behrens wrote: >>> Hi, >>> >>> I've run into one of my favorite problems in Smalltalk and decided to >>> try the list. Please don't shoot me on this one; perhaps you've run >>> into it yourself. If there are discussions that I should read, please >>> send me some info. >> >> Hi Otto, >> >> Well, you asked for comments. This is my personal opinion, which varies >> quite a bit from most implementations, since it's a bit 'old-school >> Smalltalk'. But I think the scheme below does fairly neatly distinguish >> the purposes of the various messages, which have gotten muddied over the >> years as new developers use the language somewhat differently. But maybe >> it was never the way I think I remember it being. :-) >> >> >> #printString and #printOn: >> These should answer a human-readable description of the receiver. The >> description does not need to include the class name, though it can. All >> objects should respond to these messages. Generally, #printString should >> be implemented in terms of #printOn: -- if you're writing to a stream >> you may not want to pay the cost of creating an extra string. >> #printString is the equivalent of other languages' toString(). >> >> #asString >> There should not be an Object>>asString. This message is *only* for >> converting string-like things to actual strings. So it would be >> implemented in String (to return self) and in Symbol, and *maybe* in >> things like ByteArray (where it does not *describe* the byte array, but >> answers a string whose characters have the values of the bytes). >> >> #storeString >> Produces legal Smalltalk source code that when executed will produce an >> equivalent object to the receiver. Needs to be implemented only for >> objects that can be specified as literals in Smalltalk syntax, but could >> probably be implemented for a few other simple objects. >> >> #displayString and so on. >> UI frameworks and applications will need to have their own ways of >> textually representing objects, so will add their own messages such as >> #displayString. The *only* messages that any application or framework >> can depend on *all* objects responding to are those that it defines >> itself, and #printString and #printOn:. >> >> Regards, >> >> -Martin >> > > > > |
On 03.01.2014, at 21:31, Frank Shearar <[hidden email]> wrote: > On 3 January 2014 20:08, Tobias Pape <[hidden email]> wrote: >> Hi, >> >> I think Martin makes a very good point about >> the various *String messages. >> Should we aim for that in >4.5? > > Yes :) > > frank You mean, deprecate Object>>#asString? Sounds right, although it is quite handy at times ;) - Bert - >> Best >> -Tobias >> >> >> Begin forwarded message: >> >>> From: Martin McClure <[hidden email]> >>> Subject: Re: [Pharo-dev] [Glass] printString and asString >>> Date: 3. Januar 2014 20:55:20 MEZ >>> To: Otto Behrens <[hidden email]> >>> Cc: Discusses Development of Pharo <[hidden email]> >>> Reply-To: Pharo Development List <[hidden email]> >>> >>> On 01/03/2014 12:33 AM, Otto Behrens wrote: >>>> Hi, >>>> >>>> I've run into one of my favorite problems in Smalltalk and decided to >>>> try the list. Please don't shoot me on this one; perhaps you've run >>>> into it yourself. If there are discussions that I should read, please >>>> send me some info. >>> >>> Hi Otto, >>> >>> Well, you asked for comments. This is my personal opinion, which varies >>> quite a bit from most implementations, since it's a bit 'old-school >>> Smalltalk'. But I think the scheme below does fairly neatly distinguish >>> the purposes of the various messages, which have gotten muddied over the >>> years as new developers use the language somewhat differently. But maybe >>> it was never the way I think I remember it being. :-) >>> >>> >>> #printString and #printOn: >>> These should answer a human-readable description of the receiver. The >>> description does not need to include the class name, though it can. All >>> objects should respond to these messages. Generally, #printString should >>> be implemented in terms of #printOn: -- if you're writing to a stream >>> you may not want to pay the cost of creating an extra string. >>> #printString is the equivalent of other languages' toString(). >>> >>> #asString >>> There should not be an Object>>asString. This message is *only* for >>> converting string-like things to actual strings. So it would be >>> implemented in String (to return self) and in Symbol, and *maybe* in >>> things like ByteArray (where it does not *describe* the byte array, but >>> answers a string whose characters have the values of the bytes). >>> >>> #storeString >>> Produces legal Smalltalk source code that when executed will produce an >>> equivalent object to the receiver. Needs to be implemented only for >>> objects that can be specified as literals in Smalltalk syntax, but could >>> probably be implemented for a few other simple objects. >>> >>> #displayString and so on. >>> UI frameworks and applications will need to have their own ways of >>> textually representing objects, so will add their own messages such as >>> #displayString. The *only* messages that any application or framework >>> can depend on *all* objects responding to are those that it defines >>> itself, and #printString and #printOn:. >>> >>> Regards, >>> >>> -Martin >>> >> >> >> >> > |
On 4 January 2014 13:22, Bert Freudenberg <[hidden email]> wrote:
> > On 03.01.2014, at 21:31, Frank Shearar <[hidden email]> wrote: > >> On 3 January 2014 20:08, Tobias Pape <[hidden email]> wrote: >>> Hi, >>> >>> I think Martin makes a very good point about >>> the various *String messages. >>> Should we aim for that in >4.5? >> >> Yes :) >> >> frank > > You mean, deprecate Object>>#asString? > > Sounds right, although it is quite handy at times ;) Yes, deprecate Object >> #asString, and also verify that the various implementors of #printString, #printOn:, #asString and so on work the way they should, and make sense according to the purpose Martin listed. frank > - Bert - > > >>> Best >>> -Tobias >>> >>> >>> Begin forwarded message: >>> >>>> From: Martin McClure <[hidden email]> >>>> Subject: Re: [Pharo-dev] [Glass] printString and asString >>>> Date: 3. Januar 2014 20:55:20 MEZ >>>> To: Otto Behrens <[hidden email]> >>>> Cc: Discusses Development of Pharo <[hidden email]> >>>> Reply-To: Pharo Development List <[hidden email]> >>>> >>>> On 01/03/2014 12:33 AM, Otto Behrens wrote: >>>>> Hi, >>>>> >>>>> I've run into one of my favorite problems in Smalltalk and decided to >>>>> try the list. Please don't shoot me on this one; perhaps you've run >>>>> into it yourself. If there are discussions that I should read, please >>>>> send me some info. >>>> >>>> Hi Otto, >>>> >>>> Well, you asked for comments. This is my personal opinion, which varies >>>> quite a bit from most implementations, since it's a bit 'old-school >>>> Smalltalk'. But I think the scheme below does fairly neatly distinguish >>>> the purposes of the various messages, which have gotten muddied over the >>>> years as new developers use the language somewhat differently. But maybe >>>> it was never the way I think I remember it being. :-) >>>> >>>> >>>> #printString and #printOn: >>>> These should answer a human-readable description of the receiver. The >>>> description does not need to include the class name, though it can. All >>>> objects should respond to these messages. Generally, #printString should >>>> be implemented in terms of #printOn: -- if you're writing to a stream >>>> you may not want to pay the cost of creating an extra string. >>>> #printString is the equivalent of other languages' toString(). >>>> >>>> #asString >>>> There should not be an Object>>asString. This message is *only* for >>>> converting string-like things to actual strings. So it would be >>>> implemented in String (to return self) and in Symbol, and *maybe* in >>>> things like ByteArray (where it does not *describe* the byte array, but >>>> answers a string whose characters have the values of the bytes). >>>> >>>> #storeString >>>> Produces legal Smalltalk source code that when executed will produce an >>>> equivalent object to the receiver. Needs to be implemented only for >>>> objects that can be specified as literals in Smalltalk syntax, but could >>>> probably be implemented for a few other simple objects. >>>> >>>> #displayString and so on. >>>> UI frameworks and applications will need to have their own ways of >>>> textually representing objects, so will add their own messages such as >>>> #displayString. The *only* messages that any application or framework >>>> can depend on *all* objects responding to are those that it defines >>>> itself, and #printString and #printOn:. >>>> >>>> Regards, >>>> >>>> -Martin >>>> >>> >>> >>> >>> >> > > |
Free forum by Nabble | Edit this page |