yes for tool support even if I would like to have the code of the core to be
nicely and consistently formatted.
Since I learned smalltalk with VW I like
> someVar = someValue
> | ifTrue: [self doOneThing]
> | ifFalse:
> | [self
> | doOtherThing ;
> | doYetAnotherThing.
> | anotherObject doSomething]
:)
But I can understand that other prefer the
ifTrue: [
self
doOtherThing ;
doYetAnotherThing.
anotherObject doSomething]
On Mar 4, 2010, at 7:10 PM, 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
