Another visual problem with "[" and "]" is that they are but one character, and if you place them together with something else, like "[self", they lose their visual identity (btw, we read words in chunks not by characters) and get harder to spot. It's true that some fonts and extra coloring could solve this problem, but whitespace is always the best and least invasive design weapon.
Tudor, for what its worth, the white-space surrounding the blocks is not really at issue or discussion here. It's about formatting blocked code into rectangular shapes. In fact, I agree with you about your point about the whitespace. IOW, I prefer: someVar = someValue ifTrue: [ self doOneThing ] ifFalse: [ self doOtherThing ; doYetAnotherThing. anotherObject doSomething ] Not: someVar = someValue ifTrue: [self doOneThing] ifFalse: [self doOtherThing ; doYetAnotherThing. anotherObject doSomething] Perhaps if you looked at a longer method example, with nested blocks, you might be able to "see", visually, the blocks more obviously. Perhaps not, I don't know. Regards, Chris
The lines are clearly belonging together, [ is clearly observed and clicking anywhere on the first line after [ will select the whole block.
Yet another thing it solves is the consistency between block and method. They both define behavior, and thus  it would be great if they would be treated similarly. This is better seen in the context of a block with parameter:
aCollection do: [ :each | Â Â Â Â Â Â Â Â self something. Â Â Â Â Â Â Â Â self somethingElse. ]
Just like a method has the top line with the signature and the parameters, a block should be the same. In this case, each is a parameter and it is clearly distinct from everything else. When there is no parameter, this is information made very clear, too (because of the absence of anything following [ ).
An argument against this convention was that it looks like C and that blocks are not dumb {. While I understand the built-in adversity, we are talking about a visual notation that makes sense for Smalltalk and not one that make it different from everything else around us.
Another option would be to have: boolean ifTrue:     [    self clearCaches.         self current soleInstance yada yada blah blah         self recomputeAngle ]
with everything inside the block being aligned. However, this has the problem of wasting space. One space can also be used, but only when the font is monospaced, so it would not work in general. Furthermore, it would be inconsistent or even more space wasting when it comes to blocks with parameters.
Cheers, Doru
On 4 Mar 2010, at 03:38, Chris Muller wrote:
  ifTrue: [     line1 yo.     line2 eh ]
Horrible, horrible, horrible ;) Â Poor block. Â The block is an object...
Exactly what I was thinking; and how some of the new editor features since 3.9, that seem to reify "statements". Â For example, clicking inside parens or square-brackets selects that statement(s). Â I also really enjoyed the ability to "surround", thereby creating additional statement-levels.
The whole interaction becomes much more liked working with tiled code rather than a text-editor.
I think the conclusion has to be (and I can confirm that the VisualWorks team was equally divided) that no one formatting regime will make every one happy and that all regimes will make a substantial minority unhappy. Â So perhaps we should step up to having code formatted automatically according to tailorable preferences.
My only concern is comment formatting but the way to deal with that is to use automatic formatting and deal with comment problems as they arise. Â I always used to be concerned about e.g. comments spanning multiple lines. Â But without day to day exposure I don't think one can know how much of an issue it is.
As someone who's logged 5-digits of hours in Squeak these last few years, I think the best thing is to just not. Â Let 'em wrap! Â Use shout to turn them light gray, so they don't really intrude on the code, but are there if you want focus on the extra prose.
Unfortunately, the real problem with comments within BlockNodes is how they duplicate themselves within the parse-tree.. ouch! Â I hope that is what you and Nicolas were talking about or that you'll have a fix for that..
One upside will be less effort reformatting when indent levels change. Â Have you noticed that Smalltalk tends to be more difficult to reformat than C syntax languages, I guess because of keywords? Â Not having to worry about this could be great.
Very cool, I hope there'll be enough additional consensus to adopt these Beckian formats for Squeaks pretty-print refinement.
Of course, what format gets written to a source file could still be a source of conflict ;)  We may all want our syntax to be the  format of record :)
Absolutely. Â To not, would be the machine dictating to the user. Invoking automatic formatting is always the users choice. browseWithPrettyPrint allows readers to have it formatted dynamically if they wish..
Cheers..
P.S. Â and don't get me started on the trailing period (putrid excressence), or the space between ^ and the return expression (vomitous mass).
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Live like you mean it."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project