Hi,
I do not understand the arguments that go in the direction of: because
a block is an object, it should have no spaces inside and it should
not have the code starting on a new line. This is a bit like saying
that a method should not be indented and the code should start on the
same line as the definition. Or in the same line, it is like saying
that because all statements belong to a block, they should all be
written on the same line.
Visual thinking was mentioned as a defense for these arguments, but
the first role of any visual notation is to make you identify
structure fast.
The comments of Yanni go in the correct, in my opinion, direction. So,
when you have something like:
ifTrue:
[self clearCaches.
self current soleInstance yada yada blah blah
self recomputeAngle]
you break visual alignment and it is more difficult to see that the
first "self..." is in the same context as the second "self...". Of
course, practice can solve everything and in time you can get used to
this, but that does not make it natural.
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.
Another problem with having no space between the [ and the rest is
that you basically render useless the nice feature of Smalltalk
environments to double click and select everything inside. The reason
is that I have to go to great pain to get the mouse exactly in the
right place.
An indentation like below solves the above visual problems.
boolean ifTrue: [
self clearCaches.
self current soleInstance yada yada blah blah
self recomputeAngle ]
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
