> 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 > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project