While looking around in Iliad source code, I noticed that
Object>>asResponse is implemented using Object>>printString. Dolphin Smalltalk makes a -- quite useful -- distinction between printString - what the developer wants to see displayString - what the user gets to see Since we're living in a console based environment, I guess that printString gets exercised quite a lot there. So here's my question: How about Object extend [ asResponse [ <category: 'converting'> ^Iliad.Response ok nextPutAll: self displayString; yourself ] ] Also, I'm seeing that Iliad.Response supports the "usual" streaming methods #nextPut: and #nextPutAll. What about Object extend [ asResponse [ | response | <category: 'converting'> response := Iliad.Response ok. self respondOn: response. ^response ] respondOn: aResponse [ <category: 'responding'> self displayOn: aResponse. ] ] I think that this approach could avoid (repeatedly) building and printing strings. And it would offer a non-intrusive new method #respondOn: to override in subclasses. So I could eat my cake and keep it, too: printOn: for console work, displayOn: for (possibly embedded) content representation, respondOn: for responding the object Note that I'm just venting hot air, as I have yet to write my first line of Iliad-related code .-) s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Le dimanche 21 juin 2009 à 16:27 +0200, Stefan Schmiedl a écrit :
> While looking around in Iliad source code, I noticed that > Object>>asResponse is implemented using Object>>printString. > > Dolphin Smalltalk makes a -- quite useful -- distinction > between > > printString - what the developer wants to see > displayString - what the user gets to see > > Since we're living in a console based environment, I guess > that printString gets exercised quite a lot there. > > So here's my question: How about > > Object extend [ > asResponse [ > <category: 'converting'> > ^Iliad.Response ok > nextPutAll: self displayString; > yourself > ] > ] > > Also, I'm seeing that Iliad.Response supports the "usual" > streaming methods #nextPut: and #nextPutAll. What about > > Object extend [ > asResponse [ > | response | > <category: 'converting'> > response := Iliad.Response ok. > self respondOn: response. > ^response > ] > respondOn: aResponse [ > <category: 'responding'> > self displayOn: aResponse. > ] > ] > > I think that this approach could avoid (repeatedly) building > and printing strings. And it would offer a non-intrusive > new method #respondOn: to override in subclasses. So I could > eat my cake and keep it, too: > printOn: for console work, > displayOn: for (possibly embedded) content representation, > respondOn: for responding the object Nico > > Note that I'm just venting hot air, as I have yet to write > my first line of Iliad-related code .-) > > s. > > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (204 bytes) Download Attachment |
In reply to this post by Stefan Schmiedl
Committed. I also modified the other classes that implemented
#asResponse. Thanks again :) Cheers! Nico Le dimanche 21 juin 2009 à 16:27 +0200, Stefan Schmiedl a écrit : > While looking around in Iliad source code, I noticed that > Object>>asResponse is implemented using Object>>printString. > > Dolphin Smalltalk makes a -- quite useful -- distinction > between > > printString - what the developer wants to see > displayString - what the user gets to see > > Since we're living in a console based environment, I guess > that printString gets exercised quite a lot there. > > So here's my question: How about > > Object extend [ > asResponse [ > <category: 'converting'> > ^Iliad.Response ok > nextPutAll: self displayString; > yourself > ] > ] > > Also, I'm seeing that Iliad.Response supports the "usual" > streaming methods #nextPut: and #nextPutAll. What about > > Object extend [ > asResponse [ > | response | > <category: 'converting'> > response := Iliad.Response ok. > self respondOn: response. > ^response > ] > respondOn: aResponse [ > <category: 'responding'> > self displayOn: aResponse. > ] > ] > > I think that this approach could avoid (repeatedly) building > and printing strings. And it would offer a non-intrusive > new method #respondOn: to override in subclasses. So I could > eat my cake and keep it, too: > printOn: for console work, > displayOn: for (possibly embedded) content representation, > respondOn: for responding the object > > Note that I'm just venting hot air, as I have yet to write > my first line of Iliad-related code .-) > > s. > > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (204 bytes) Download Attachment |
On Sun, 21 Jun 2009 17:09:29 +0200
Nicolas Petton <[hidden email]> wrote: > Committed. I also modified the other classes that implemented > #asResponse. > > Thanks again :) You're very welcome. CalendarWidget seems to be missing a date instance var. s. stefan@g128 iliad $ svn diff Index: trunk/More/Widgets/CalendarWidget.st =================================================================== --- trunk/More/Widgets/CalendarWidget.st (revision 1353) +++ trunk/More/Widgets/CalendarWidget.st (working copy) @@ -39,7 +39,7 @@ Widget subclass: CalendarWidget [ - | month | + | month date | <comment: nil> <category: 'Iliad-Core-Widgets'> > > Cheers! > > Nico > > Le dimanche 21 juin 2009 à 16:27 +0200, Stefan Schmiedl a écrit : > > While looking around in Iliad source code, I noticed that > > Object>>asResponse is implemented using Object>>printString. > > > > Dolphin Smalltalk makes a -- quite useful -- distinction > > between > > > > printString - what the developer wants to see > > displayString - what the user gets to see > > > > Since we're living in a console based environment, I guess > > that printString gets exercised quite a lot there. > > > > So here's my question: How about > > > > Object extend [ > > asResponse [ > > <category: 'converting'> > > ^Iliad.Response ok > > nextPutAll: self displayString; > > yourself > > ] > > ] > > > > Also, I'm seeing that Iliad.Response supports the "usual" > > streaming methods #nextPut: and #nextPutAll. What about > > > > Object extend [ > > asResponse [ > > | response | > > <category: 'converting'> > > response := Iliad.Response ok. > > self respondOn: response. > > ^response > > ] > > respondOn: aResponse [ > > <category: 'responding'> > > self displayOn: aResponse. > > ] > > ] > > > > I think that this approach could avoid (repeatedly) building > > and printing strings. And it would offer a non-intrusive > > new method #respondOn: to override in subclasses. So I could > > eat my cake and keep it, too: > > printOn: for console work, > > displayOn: for (possibly embedded) content representation, > > respondOn: for responding the object > > > > Note that I'm just venting hot air, as I have yet to write > > my first line of Iliad-related code .-) > > > > s. > > > > > > _______________________________________________ > > help-smalltalk mailing list > > [hidden email] > > http://lists.gnu.org/mailman/listinfo/help-smalltalk -- Stefan Schmiedl EDV-Beratung Schmiedl, Berghangstr. 5, D-93413 Cham im Büro: 09971 9966 989, am Handy: 0160 9981 6278 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefan Schmiedl
Stefan Schmiedl wrote:
> While looking around in Iliad source code, I noticed that > Object>>asResponse is implemented using Object>>printString. > > Dolphin Smalltalk makes a -- quite useful -- distinction > between > > printString - what the developer wants to see > displayString - what the user gets to see GNU Smalltalk also has the same distinction, as you surely know: 'abc' printString = '''abc''' (prints as 'abc') 'abc' displayString = 'abc' (prints as abc without quotes) > Also, I'm seeing that Iliad.Response supports the "usual" > streaming methods #nextPut: and #nextPutAll. What about > > Object extend [ > asResponse [ > | response | > <category: 'converting'> > response := Iliad.Response ok. > self respondOn: response. > ^response > ] > respondOn: aResponse [ > <category: 'responding'> > self displayOn: aResponse. > ] > ] Yes, looks nice. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Nicolas Petton
Nicolas Petton wrote:
> Committed. I also modified the other classes that implemented > #asResponse. I suggest that you implement #next:putAll:startingAt: and #next:put:. These are important to minimize copies and garbage collections, for example in the Iconv or Zlib packages. While these are not used if you do "response nextPutAll: anEncodedStream", they are part of the expected protocol for #nextPutAllOn: ("anEncodedStream nextPutAllOn: response"). They can of course be simply forwarded to the stream. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |