[squeak-dev] String>expandMacros rules?

tim Rowledge tim at rowledge.org
Mon Mar 6 18:43:29 UTC 2017


[removing some mangled quote-misattribution that doesn’t really matter ]

>>> 
>>>      ‘%-0.1e’ printf: x
>>> is a whole lot nicer than
>>>     (x printShowingDecimalPlaces: 1) padded: #left to: 1 with: $0
>> 
>> I would really say the other way round.
>> Really, frist is faster to write, but second is easier to read.
>> I don't have to memorize what character means left or right padding, what number means precision and what means overall length and such.
>> 
>> I think the first one is trying too hard (why, yes, C, I am looking at you)
> 
> My thoughts exactly!

Well there’s two parts to this
a) the ability to neatly format output for printing/displaying in textmorphs/writing to CSV or similar files/transmitting across messaging systems
b) the precise syntax used

It’s useful to be able to get a Float to print in a suitable format with alignment, precision, padding or whatever. Same with other numbers. We have quite a lot of code scattered about that does various parts of it with varying degrees of niceness. It would be nice to get it nicely aligned so that it is findable without spending too much time.

If the best way to do that is with Float>printInMaxWidth:withDecimalPlaces:aligned:paddingChar:etc:etc: then fine; it’s better than the current situation. Then to simplify life we’d probably want versions that assume default width, or precision, or padding and so on, so now you have more messages to know about. Then someone will want a simple spec language to encode the format. And we re-invent the C format in all but name and possibly incompletely anyway.

At a total cost of 53 methods across 10 classes (including unit tests) to provide a neat and simple and flexible formatter - even if you don’t like the specific spec language details - this is a pretty good deal. 

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
The problem with the gene pool is that there is no lifeguard.




More information about the Squeak-dev mailing list