> On Jul 12, 2022, at 11:49 PM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> 
> Hi Chris --
> 
> > Text is concerned with presentation -- attributes, colors, fonts -- and not really the domain side,
> > which is what #format: is dealing with.
> 
> String and Text are polymorphic in many cases. The use of #format: makes GUI scripting easier in
> several cases. The reason for using {1} over {FOO} is unrelated to that. Therefore, it makes sense
> to also add that feature to Text >> #format:.

+1000. In VisualWorks Text & String provide much of the same api for manipulation (concatenation et al), search, etc, and differ for display.  Squeak is much weaker in this regard.

The architectural issue is that Text is a kind of string, and hence anything one can do to a string one naturally expects to be able to do to a Text.  Squeak should meet that expectation and currently it does not.

> 
> Let's open another thread for that:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-July/221586.html
> 
> > See Collections-cmm.1018, which restores (mostly) the legacy performance when using
> > numeric-only tokens.
> 
> Nice! Thanks. :-)
> 
> > Speaking of which, WHAT in the heck happened to comment formatting in 6.0?
> 
> See other thread. If something got broken unintentionally, we can surely fix it:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-July/221585.html
> 
> Best,
> Marcel
>> Am 13.07.2022 03:17:47 schrieb Chris Muller <asqueaker at gmail.com>:
>> 
>> Hi Marcel,
>> 
>>> Please make sure to have Text >> #format: be on par with your changes.
>> 
>> Hmm, I noticed that, but am hesitant to continue encouraging Text to take on that responsibility.  Text is concerned with presentation -- attributes, colors, fonts -- and not really the domain side, which is what #format: is dealing with.  I see the existing implementation is optimized by directly accessing its 'runs', which I would not do.
>>  
>>> Note that you changes put more pressure on the GC:
>>> 
>>> ['Hello {1}!' format: { 'Squeak' }] bench
>>> 
>>> BEFORE: '2,320,000 per second. 432 nanoseconds per run. 1.63967 % GC time.' 
>>> AFTER: '1,340,000 per second. 746 nanoseconds per run. 16.92 % GC time.' 
>> 
>> See Collections-cmm.1018, which restores (mostly) the legacy performance when using numeric-only tokens.  The garbage you saw is necessary when using alphanumeric tokens.  This optimization complexifies the code to the limit of what I believe is reasonable to achieve extra performance.  I think people generally expect String manipulation to involve the need to produce some garbage.
>>  
>>> P.S.: If you had not opted for re-layouting the entire method, I would be able to actually see what you changed there... ;-) ... pretty-print for obfuscation, I suppose? :-D
>> 
>> For obfuscation?  Give me a break, absolutely not.  Huh?  No, I've always been a supporter of preserving the formats of original works, especially when only superficial changes are being made, but this is a long method and the change is too complex for me to be expected not to utilize what I need to be productive, which includes the use of my pretty printer, yes.
>> 
>> Speaking of which, WHAT in the heck happened to comment formatting in 6.0?  We've held off improving the pretty printer to emulate Rectangular Block for years out of respect for original authors chosen legacy format.  But this new comment formatting blows that out of the water by changing peoples' **custom-formatted** comments to  a horrendously narrow, super-tall format!  Please revert ParseNode>>#printSingleComment:on:indent:.
>> 
>> Best,
>>   Chris
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220713/83e8c272/attachment.html>