[NIT] Pretty pretting #ifFalse:ifTrue:
Doug Way
dway at riskmetrics.com
Wed Nov 21 04:58:08 UTC 2001
Bijan Parsia wrote:
>
> On Tue, 20 Nov 2001, Doug Way wrote:
>
> [snip]
> > On the other hand, some might argue that they can impart extra meaning
> > to code they've written by hand-formatting it in a certain way, which
> > should be preserved for all to see. But that seems bogus to me... it
> > certainly wouldn't outweight the benefits of reading uniformly
> > formatted code. I'd be curious to see a counterexample claim, though.
> > :)
> [snip]
>
> Given Dan Ingalls post, I don't really have more much to say about this.
> *But* the point that I was trying to raise is that the current system
> doens't just reformat, it alters the actual code, replacing *certain*
> expressions with their semantic equivalents. In other words, pretty
> printing is decompiling, and decompiling after certain code
> transformations have happened.
Yes, I definitely agree with your point about altering the code. This
goes along with Richard's definition of pretty-printing, which I agree with.
Switching ifFalse:ifTrue: to ifTrue:ifFalse: also counts as
code-altering, which a pretty-printer shouldn't do. I also like to use
ifFalse:ifTrue:, when the ifFalse: clause is much shorter than the ifTrue:.
It sounds like we're all pretty much in agreement that the
pretty-printer shouldn't reveal this sort of parse-tree optimizing. I
haven't tried Henrik's changeset, but maybe it's worth a look.
- Doug Way
dway at riskmetrics.com
More information about the Squeak-dev
mailing list
|