+1 On Mar 4, 2010, at 19:10 , Dale Henrichs wrote:
> It is obvious that a consensus will not be reached on the "one and only true > format." > > If my browser displays code formatted the way I want to see it and the > difference tools are format neutral (i.e., the source and target code is > formatted using the same rules) there is no need to agree on a standard > style. For all intents and purposes each developer's favored format _is the > standard_. > > We only need to agree to disagree and then figure out how to make it possible > to customize the formatter and resolve any other technical details > (performance and others) that are deemed important. These are technical > problems with technical solutions. > > Dale > ----- "Chris Muller" <[email protected]> wrote: > > | > 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 > | >> [email protected] > | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | > > | > -- > | > www.tudorgirba.com > | > > | > "Live like you mean it." > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > [email protected] > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | > > | > | _______________________________________________ > | Pharo-project mailing list > | [email protected] > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
