> 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
