Hi All,

Lots to be said about all of this. But I'm going to stick with a few points:

a) The "roles" are typically described by the names of variables quite
clearly. Hardly ever we will see an instance (or temporary) variable which
is named after the "type" (sometimes we do but it's really bad style).

b) What these roles *mean* is quite a different matter and cannot be very
well described by any system I am aware about - contrary to types which have
fixed sets of responsibilities the roles are much more variable. The role of
being the "closeButton" for a window is quite different from being the
"inheritanceButton" in a browser or a "sendButton" in an email program. It
would be an amazingly interesting piece of work to try to have a "role
inferencer" which identifies what (for example) the responsibility for some
object in a concrete role is (though I am not certain I would want to spend
my time on it - it may easily lead to a dead end given that we cannot even
deal with types very well).

c) One of the overwhelming reasons for using type names instead of role
names in method arguments is simply because of the absence of any type
inferencer that "actually works" to the degree that it gives useful
informations about the types involved. It is because of that plus the
problem of having to avoid duplicate names for args vs. variables that I
find using type names a reasonable style.

d) One of the reasons why I think type inferencers work so poorly is because
of the lack of strong enough models in the underlying system. "Just
guessing" about messages being sent here and there isn't going to work in my
understanding - any type inferencer which is worth its money probably will
need some "hints" by framework designers so that users of the framework can
have the type inferencer do its work. So some form of "type annotations"
will be required to make it work.

Okay, stopping myself right here and now. I could go on for hours on this
;-)

Cheers,
  - Andreas

----- Original Message ----- 
From: "ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, February 28, 2004 8:34 PM
Subject: Re: Squeak coding style...


Hi dan

what you describe is a kind of dream. Just before the BC compiler
arrived, I started to write another pretty printer
but based on the Squeak AST.  Then I stopped because I thought that the
AST would change. I was never happy with the result.
But in the process I learned that
- the AST design can also help a lot (lex confirmed that in lucid)
having for example a parent link as in RB AST makes a lot of stuff
easier,
- having a Visitor is a good to achieve variation for the pretty
printers (note the s). because this visitor could be used to
fileout code also or generate new syntax or HTML.
- I was really not happy at all with my result because it was not
clever enough to be tweaked. Also writing the tests
for the pretty printer was difficult because testing the AST was not
good, but testing the resulting pretty printed code
was tedious because everytimes I took into account a new construct I
may break a lot of tests. Still I wanted to be sure
that all the case were well printed.

For the type inferencer, Gilad Bracha was visiting us recently and he
made a really improtant point about the
idea that you want to have pluggable type system: type system that do
not interfere with the language semantics.
I will ask him if I can put the slides on the web. One nice consequence
is that in fact you would like to be able to annotate
any AST elements and also instance variables.
So this could be a task for the Compiler Cleaning effort: using the RB
AST will already be a step in that direction (this
was sad to see that Lex, Anthony and me did the same effort in parallel
because we needed

For the type or role, I think that this is extremely  important for the
instance variables.
So normally I used roles for instance variables and type for arguments.
But I agree I would really value a type inferencer.
May be this is the time to make call for tools :)

Stef

On 28 févr. 04, at 19:32, Dan Ingalls wrote:

>> I agree with this. Removing formatting from code is really a "lossy
>> compression" and it looses lots of valuable information. And it's not
>> just
>> that poorly formatted code is often a sign of inexperience or bugs -
>> it's
>> also that (at least for me) the style and consistency of a method
>> says a lot
>> about who has written it, how many people have been working on it and
>> similar things. In short, the way in which a method is formatted
>> reveils a
>> lot of subtle information about the writer, its intent and its general
>> working style. I am not certain we want to loose that information.
>
> I agree with Andreas about this, but I think it is more a statement
> about loss in our current formatter than about the impossibility of
> good automatic formatting.  I think we could get *quite close* to
> something that made us all happy with just a bit more energy put into
> the formatter.
>
> For instance...
>
> 1.  Include more white space as real information.  I *think* this is
> what bothers Andreas about lossiness of the current formatter.  For
> instance, skipping a line between significant sections is one of the
> most useful gestures in good coding.  Also comments embedded in, or to
> the right of code are different from line-long comments, and ought to
> be kept as such.
>
> 2.  Make it easy to personalize the formatter with regard to such
> issues as spaces around binary ops and return arrow, empty line before
> code, block header spading, etc.  A set of check boxes and a method in
> view that changes as you check them.
>
> 3.  Put some work into the defaults, with input from the community and
> suggestions like Kent's.
>
> While I know everyone feels differently about various details, I don't
> think that a wonderful formatter should be considered an
> impossibility.  I worked pretty hard on the current one years ago, but
> stopped short of some of the white space subtleties.
>
> It would be nice to have a "benchmark" piece of code that included
> both challenging structures and tasteful commenting and code.  Then we
> could all judge whether we basically approved or disapproved of a
> given formatter (and it's personalizing options).  Each time someone
> came up with a new challenge, its archetypal example could be added to
> the benchmark and the formatter tweaked until we were happy with the
> result.
>
> - Dan
>
> PS:  On the topic of variable names, I happen to oppose the "aString"
> style of variable naming except when you really can't think of
> anything better.  I feel a variable should be typed by its type, and
> named by its role (ie "boxCount" instead of "anInteger".
> Unfortunately we don't have a type inference system and a button to
> show the types when we want them.  Me, I'm going to keep naming by
> role, and encouraging work on type inference.
>