Smalltalk › Pharo › Pharo Smalltalk Developers

About nextPutAll: $(

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

Igor Stasenko

Re: About nextPutAll: $(

We all want to escape from routine, tedious and repeatable tasks..

But unfortunately there is some of them when it is going to stay no matter how you want to optimize, and implementing printing is one of good examples of such tasks.

Adding 'convenience' methods won't help.. it will just balkanize new printing stuff from one that lies there for years. In thousands of projects.. because it is one of the central necessities, to see what your objects contain or to report something somewhere in readable form, and that involves *drumroll* printing :)

On 27 July 2015 at 15:15, Igor Stasenko <[hidden email]> wrote:

On 27 July 2015 at 12:23, stepharo <[hidden email]> wrote:

May be I raised a not important issue.

My impression too. :)

Stef

Le 27/7/15 09:53, Peter Uhnák a écrit :

stream surround: aBlock between: '( ' and: ' )'

This may be personal preference, but I do not like having more method arguments after a block argument... because if the block is longer it may not be visible...

e.g.

stream

surround: [ :aStream |

self size > 100

ifTrue: [

aStream nextPutAll: 'size '.

self size printOn: aStream ]

ifFalse: [

self keysSortedSafely

do: [ :key |

aStream

print: key;

nextPutAll: '->';

print: (self at: key);

space ] ] ]

between: $(

and: $)

vs between:and:surround:

if you actually run this through formatter in Pharo, the between:and: is not even visible --- you have to scroll to see it. Of course if aBlock is a variable, than my argument falls.

From visual perspective the current state actually isn't that bad because you immediately see where is beginning and where is end without even looking... with surround:between:and: not so much...

Peter

--
Best regards,
Igor Stasenko.

Best regards,
Igor Stasenko.

Ben Coman

Re: About nextPutAll: $(

In reply to this post by stepharo

> Le 27/7/15 09:53, Peter Uhnák a écrit :
>
>
>> stream surround: aBlock between: '( ' and: ' )'
>
>
> This may be personal preference, but I do not like having more method
> arguments after a block argument... because if the block is longer it may
> not be visible...

+1

> e.g.
>
> stream
> surround: [ :aStream |
> self size > 100
> ifTrue: [
> aStream nextPutAll: 'size '.
> self size printOn: aStream ]
> ifFalse: [
> self keysSortedSafely
> do: [ :key |
> aStream
> print: key;
> nextPutAll: '->';
> print: (self at: key);
> space ] ] ]
> between: $(
> and: $)
>
> vs between:and:surround:

That could even be #between:and:putAll:

On Sat, Jul 25, 2015 at 4:48 AM, stepharo <[hidden email]> wrote:

> HI
>
> while working on a lecture I saw that we have about 75 cases like:
>
> aStream nextPut: $(.
> ....
> aStream nextPut: $).
>
> ... we have surroundedBy: aString
>
> But only working on aString.

Well it seems that #surroundedBy: only has one sender
#surroundedBySingleQuotes which in turn seems to be not sent anywhere.
So actually #surroundedBy: seems ripe for culling to be replaced by
more generic...

aStream between: '(' and: ')' putAll: [ ... nextLevelIn ... ].

Now for most of those 75 cases and other cases where this pattern
might apply, is performance so critical that using $( rather than '('
gains a lot? Perhaps on ancient machine and before Cog it was
important but now using $( now is premature optimisation? Otherwise we
might also need #betweenChars:and:putAll:

On Mon, Jul 27, 2015 at 3:59 PM, Denis Kudriashov <[hidden email]> wrote:
> In most cases we always surround text by "()". Can we just provide method
> for this and not duplicate "between: '( ' and: ' )'" everywhere? Something
> like "stream>>printInBrackets:"

Maybe it is also a useful pattern for markup languages:

aStream between: '<HEAD>' and: '</HEAD>' putAll: [
... nextLevelIn ... ].

On Sun, Jul 26, 2015 at 1:40 AM, Esteban Lorenzano <[hidden email]> wrote:
> (From my vacations)
>
> Doesn't this solves the problem?
>
> stream << $( << name << $)
>
> It is already there :)

That is a reasonable point, but I think the having start and end
tokens in visual close proximity has a slight advantage.

On Mon, Jul 27, 2015 at 6:23 PM, stepharo <[hidden email]> wrote:
> May be I raised a not important issue.

Of course its easier to have an opinion on simple things.
cheers -ben

Peter Uhnak

Re: About nextPutAll: $(

is performance so critical that using $( rather than '('
gains a lot?

There's visual gain that I've mentioned. If you replace $( with '(' then my argument about visibility fails. $( is very distinct.

Maybe it is also a useful pattern for markup languages:

aStream between: '<HEAD>' and: '</HEAD>' putAll: [
... nextLevelIn ... ].

I don't think it's a good practice to generate individual tags by hand, you should have more abstraction.

Pillar has

PRHTMLTag>>with: aString

stream << $> << aString << '</' << name << $>

Apart from it being hard to read due to </> it's so simple that it doesn't matter and you have little to no gain in trying to make it "nicer".

Peter

stepharo

Re: About nextPutAll: $(

Probably that the gain is not enough.
This is just annoying to not have surrounding.

Le 27/7/15 18:20, Peter Uhnák a écrit :

is performance so critical that using $( rather than '('
gains a lo

There's visual gain that I've mentioned. If you replace $( with '(' then my argument about visibility fails. $( is very distinct.

Maybe it is also a useful pattern for markup languages:

aStream between: '<HEAD>' and: '</HEAD>' putAll: [
... nextLevelIn ... ].

I don't think it's a good practice to generate individual tags by hand, you should have more abstraction.

Pillar has

PRHTMLTag>>with: aString

stream << $> << aString << '</' << name << $>

Apart from it being hard to read due to </> it's so simple that it doesn't matter and you have little to no gain in trying to make it "nicer".

Peter

Henrik Sperre Johansen

Re: About nextPutAll: $(

On 27 Jul 2015, at 7:42 , stepharo <[hidden email]> wrote:

Probably that the gain is not enough.
This is just annoying to not have surrounding.

Le 27/7/15 18:20, Peter Uhnák a écrit :

is performance so critical that using $( rather than '('
gains a lo

There's visual gain that I've mentioned. If you replace $( with '(' then my argument about visibility fails. $( is very distinct.

Maybe it is also a useful pattern for markup languages:

aStream between: '<HEAD>' and: '</HEAD>' putAll: [
... nextLevelIn ... ].

I don't think it's a good practice to generate individual tags by hand, you should have more abstraction.

Pillar has

PRHTMLTag>>with: aString

stream << $> << aString << '</' << name << $>

Apart from it being hard to read due to </> it's so simple that it doesn't matter and you have little to no gain in trying to make it "nicer".

Peter

Faced with a choice of using multiple nextPut: / nextPutAll:'s, and using a selector like surround:with:and:, or was that put:and:around:, or did it included between: somehow?

I think I know which I'd end up writing every single time.

Same reason I think a lot of the specialized collect:/select:'s out there is pure bloat in a base image, and better left defined to users who prefer it.

Cheers,

Henry

stepharo

Re: About nextPutAll: $(

>>> Apart from it being hard to read due to </> it's so simple that it
>>> doesn't matter and you have little to no gain in trying to make it
>>> "nicer".
>>>
>>> Peter
>>>
>>
>
> Faced with a choice of using multiple nextPut: / nextPutAll:'s, and
> using a selector like surround:with:and:, or was that put:and:around:,
> or did it included between: somehow?
> I think I know which I'd end up writing every single time.
>
> Same reason I think a lot of the specialized collect:/select:'s out
> there is pure bloat in a base image,

Can you give an example?

> and better left defined to users who prefer it.

>
> Cheers,
> Henry

Eliot Miranda-2

Re: About nextPutAll: $(

In reply to this post by hernanmd

On Sat, Jul 25, 2015 at 9:39 AM, Hernán Morales Durand <[hidden email]> wrote:

In BioSmalltalk I use this pattern a lot:

    aStream
        nextPutAll: self name
        between: $[ -> $].

so yes, that would be a nice inclusion for me :)

i don't like the allocation here; v slow. why not nextPutAll:between:and: ?

Cheers,

Hernán

2015-07-24 17:48 GMT-03:00 stepharo <[hidden email]>:
HI

while working on a lecture I saw that we have about 75 cases like:

aStream nextPut: $(.
....
aStream nextPut: $).

storeOn: aStream
"Store a description of the elements of the complement rather than self."

aStream nextPut: $(.
absent storeOn: aStream.
aStream nextPut: $); space; nextPutAll: #complement.

printElementsOn: aStream
aStream nextPut: $(.
self size > 100
ifTrue: [aStream nextPutAll: 'size '.
self size printOn: aStream]
ifFalse: [self keysSortedSafely
do: [:key | aStream print: key;
nextPutAll: '->';
print: (self at: key);
space]].
aStream nextPut: $)

we have surroundedBy: aString

surroundedBy: aString
^ self class streamContents: [ :s|
s nextPutAll: aString.
s nextPutAll: self.
s nextPutAll: aString ].

But only working on aString.
To me it looks like it ia class for having it on stream.

What do you think?

_,,,^..^,,,_

best, Eliot

hernanmd

Re: About nextPutAll: $(

2015-07-29 20:09 GMT-03:00 Eliot Miranda <[hidden email]>:

On Sat, Jul 25, 2015 at 9:39 AM, Hernán Morales Durand <[hidden email]> wrote:
In BioSmalltalk I use this pattern a lot:

    aStream
        nextPutAll: self name
        between: $[ -> $].

so yes, that would be a nice inclusion for me :)

i don't like the allocation here; v slow. why not nextPutAll:between:and: ?

Because I wasn't very inspired :)

Thanks!

Hernán

Cheers,

Hernán

2015-07-24 17:48 GMT-03:00 stepharo <[hidden email]>:
HI

while working on a lecture I saw that we have about 75 cases like:

aStream nextPut: $(.
....
aStream nextPut: $).

storeOn: aStream
"Store a description of the elements of the complement rather than self."

aStream nextPut: $(.
absent storeOn: aStream.
aStream nextPut: $); space; nextPutAll: #complement.

printElementsOn: aStream
aStream nextPut: $(.
self size > 100
ifTrue: [aStream nextPutAll: 'size '.
self size printOn: aStream]
ifFalse: [self keysSortedSafely
do: [:key | aStream print: key;
nextPutAll: '->';
print: (self at: key);
space]].
aStream nextPut: $)

we have surroundedBy: aString

surroundedBy: aString
^ self class streamContents: [ :s|
s nextPutAll: aString.
s nextPutAll: self.
s nextPutAll: aString ].

But only working on aString.
To me it looks like it ia class for having it on stream.

What do you think?

--
_,,,^..^,,,_
best, Eliot

Hannes Hirzel

Re: About nextPutAll: $(

In reply to this post by Eliot Miranda-2

On 7/29/15, Eliot Miranda <[hidden email]> wrote:

> On Sat, Jul 25, 2015 at 9:39 AM, Hernán Morales Durand <
> [hidden email]> wrote:
>
>> In BioSmalltalk I use this pattern a lot:
>>
>> aStream
>> nextPutAll: self name
>> between: $[ -> $].
>>
>> so yes, that would be a nice inclusion for me :)
>>
>
> i don't like the allocation here; v slow. why not nextPutAll:between:and:
> ?

>
>>
>> Cheers,
>>
>> Hernán
>>
>>
>>
>>
>> 2015-07-24 17:48 GMT-03:00 stepharo <[hidden email]>:
>>
>>> HI
>>>
>>> while working on a lecture I saw that we have about 75 cases like:
>>>
>>> aStream nextPut: $(.
>>> ....
>>> aStream nextPut: $).
>>>
>>>
>>>
>>> storeOn: aStream
>>> "Store a description of the elements of the complement rather than
>>> self."
>>>
>>> aStream nextPut: $(.
>>> absent storeOn: aStream.
>>> aStream nextPut: $); space; nextPutAll: #complement.
>>>
>>>
>>> printElementsOn: aStream
>>> aStream nextPut: $(.
>>> self size > 100
>>> ifTrue: [aStream nextPutAll: 'size '.
>>> self size printOn: aStream]
>>> ifFalse: [self keysSortedSafely
>>> do: [:key | aStream print: key;
>>> nextPutAll: '->';
>>> print: (self at: key);
>>> space]].
>>> aStream nextPut: $)
>>>
>>> we have surroundedBy: aString
>>>
>>> surroundedBy: aString
>>> ^ self class streamContents: [ :s|
>>> s nextPutAll: aString.
>>> s nextPutAll: self.
>>> s nextPutAll: aString ].
>>>
>>> But only working on aString.
>>> To me it looks like it ia class for having it on stream.
>>>
>>> What do you think?
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>