Hi Marcel,

Thank you very much for your in-depth response!

On 4/4/22 08:22, Marcel Taeumel wrote:
> Hi Lauren --
> 
> Let me assume that you want to write source code that is extensible, re-usable, and maintainable. While Smalltalk supports various paradigms, let me further assume that you want to learn how to write using an object-oriented style where you objects remain extensible, re-usable, and maintainable.
You're spot on.  Most of my experience is writing function-oriented
programs, so Smalltalk seems a bit backwards.  I'm getting the hang of
it, though.  Slowly.

> That is, for example, single inheritance may demand for other strategies to implement and document cross-cutting concerns (i.e., concerns whose implementation cross-cuts the primary decomposition).
> 
> Well, I don't know about your current projects and goals. What I can further share is my perspetive on how to write good object-oriented code for the Squeak/Smalltalk system, given its shared object space, programming tools, and language concepts.
Single inheritance and a shared message name space have been pain points
after coming from multiple inheritance and message name spaces, so your
input is very enlightening.

> Provided that I can somehow figure out a good way to decompose the problem into classes that match domain concepts
The way I've been thinking of classes is totally different, since I'm
coming from function-oriented land.  To me, a class has nothing to do
with domain concepts other than the data flowing between them.  I
hadn't, and wouldn't have, considered making a class for the purpose of
specifying HowToDoSomething.  That would have gone into specially named
messages, like #do*By*.  It worked, but I was fighting Smalltalk, not
using it, by using a minimal number of classes, and I couldn't tell what
I was doing wrong that made it so difficult.

> Well, objects send messages to each other. There are no "private" messages per se. Thus, I try to make it possible to be able to send any message to an object at any time. Regardless of it's state. That makes it easier to inspect objects and debug their state. Sometimes, this may lead to larger methods, but often these can typically be regarded short. Yet, I don't care. My goal is to write robust protocols. Consequently, I will not split up a method into parts for the reason of length but rather for the reasons of re-usability and extensibility. It should still be possible to easily inspect instances and poke around with some message sends to better understand what's going on.
> 
> I hope this helps. You can read about my most recent work that tries to follow these suggestions via TTFontReader in Trunk. Even for that performance thing. :-)
Reading through TTFontReader was very educational.  I had expected
TTFontDescription to build itself, as that's usual practice in the
languages I'm familiar with, but I think I understand why it didn't.
One concern is "build the object from raw data" and another is "access
processed data"; they get separate classes because they're unrelated.
If you had a different raw data format you'd only have to replace the
"build the object from raw data" class, and you might be able to re-use
parts by subclassing.

> To me, your thoughts indicate some bias toward performance
optimization. So, let me further suggest that you put those concerns
aside for now.
>
> P.S.: If you are looking for more fine-grained ways to optimize a specific algorithm of yours, ask Levente as he has many useful tricks in how to write methods that should produce efficient byte codes. ;-) Yet, at that microscopic level, it's not primarily about object-oriented design anymore.
I'm afraid I've done so much low-level programming it's practically
second nature.  Gotta write maintainable code before worrying about
that, anyways.  I'll leave the hand optimizing tricks to Levente for
now.  ;)

Thank you so much,
Lauren