Iliad - asResponse implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Iliad - asResponse implementation

Stefan Schmiedl
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
Reply | Threaded
Open this post in threaded view
|

Re: Iliad - asResponse implementation

Nicolas Petton
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
Indeed, this approch is better. Thanks!

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
Reply | Threaded
Open this post in threaded view
|

Re: Iliad - asResponse implementation

Nicolas Petton
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
Reply | Threaded
Open this post in threaded view
|

Re: Iliad - asResponse implementation

Stefan Schmiedl
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
Reply | Threaded
Open this post in threaded view
|

Re: Iliad - asResponse implementation

Paolo Bonzini-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Iliad - asResponse implementation

Paolo Bonzini-2
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