Peter Smet wrote:

>
>  >Use common sense.  If you add a #mod12 method to Integer, because
>  >you need integers mod 12, what happens when you or someone else
>  >needs integers mod 10?  mod 2? and so on?  Would it make sense
>  >to have a different #modN message for all N?
>
>  Except that when you look in the collection classes, there really are
>  methods like first, second, third and fourth..... Where do we stop?
>  sevenhundredandone?

Well, that would actually have to be #sevenHundredAndFirst.

But your point is well taken.  A good principle I remember reading early
in my comp-sci education (wish I could remember the author/book)
stated that although most values were arbitrary, certain values could
be treated as first class (and hence could be used without explanation
or apology), such as 0 and 1.  That does call #second into question,
though, doesn't it?  Like I said, not everything in Squeak should be
taken as gospel (as has been said many times of VisualWorks).

>
>  >If you want to learn how to do things right, it is probably best to adopt
>  >good practices from the beginning.
>
>  Put the method where it fits best. I get warning bells when I write code
>  like:
>  aMessage args do this. aMessage args do that.
>  I have found in cases where you have to keep extracting parameters in this
>  fashion that I am probably writing the method in the wrong class. In the
>  above example, I put the method in Message, and things were immediately much
>  shorter and cleaner (whenever your code gets smaller you have probably done
>  something right).

As any chess grandmaster will tell you, the heuristics you read in chess books
only take you so far.  Many an expert has lost to a master because he followed
the heuristics, instead of evaluating the situation on its actual merits.

The same goes for programming heuristics (a.k.a "software engineering
principles," "good style," etc.).

You have a valid point.  Others have made the same observation.  I take the
metric you have indicated into consideration when I code, but I decide what
to do based on additional factors.  For example, "aFoo someAttribute 
doSomething"
may be fine, provided "aFoo" inherently would have "someAttribute," which would
inherently be able to "doSomething." On the other hand, if the fact 
that it has the
attribute is an arbitrary detail of its implementation, then a design 
change would
be indicated.  Otherwise, constructs such as "(aString at: 2) 
isUppercase" would
all have to be replaced with "aString secondCharIsUppercase."  There is a big
difference between encapsulated attributes and well-known associative 
references.

>
>  Smalltalk, unfortunately, is so different from other languages that you will
>  likely find it a major hurdle to learn. I hope you persist, because you will
>  eventually find yourself solving problems faster and easier than you ever
>  have. I have found that every language 'gets in the way' when you program.
>  What I love about Smalltalk is that it is the most unobtrusive language I
>  have worked with in this regard.
>
>  Anyway, keep the group posted about how you fare - we are more than willing
>  to help.
>
>  Peter

It's not "Smalltalk, The Language" that is hard to learn.  It's the 
philosophy, the
style and the libraries that pose a challenge.

--Alan




Content-Type: text/x-vcard; charset=us-ascii;
  name="sourcery.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Alan Lovejoy
Content-Disposition: attachment;
  filename="sourcery.vcf"

Attachment converted: Anon:sourcery.vcf 13 (TEXT/R*ch) (0000B0F0)