[NIT] Pretty pretting #ifFalse:ifTrue:

Bijan Parsia bparsia at email.unc.edu
Wed Nov 21 02:50:19 UTC 2001


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.

The case that made me twig was a switch from ifFalse:ifTrue: to
ifTrue:ifFalse:. But I had encountered the problem earlier when a dummy
ifFalse: branch kept getting removed. I didn't quite know what to put in
the ifFalse:, so I just put a nil place holder with a comment attached. I
didn't even *remember* that I was browsing with prettyPrint and it kept
nuking my (rather complex) comment. Tres annoyant.

I use ifFalse:ifTrue: when it seems more natural to me, and it
communicates *something* I think. That's more than a case of eliminating
hand formatting, I'd say :) I think you could *have* coding standards that
mandated only using #ifTrue:ifFalse:. In that case it would be handy to
have the transformation. But I don't think this is a good *baseline*,
espeically when the transformations are accidents of the compilers
particular optimizations.

(It also makes the #ifTrue:ifFalse: seem less like a message!)


And just so this isn't a repeat message, I'll point to Dandelion:

http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/dandelion/index.html

Which looks like a very neat system (even if I've not traced exactly
where/how it does code formatting :). Actually, just the "Dynamic
Document" facilities seem worth investigating. In any case, Dandelion
seems to be well suited as a flexible "fileing out" framework. It already 
generates several different sorts of file out, including an XML based
one.)

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list