Am Dienstag, dem 06.01.2026 um 14:29 -0500 schrieb Mark Bratcher:
> It's not easy diving into OOP at this level without general OOP
> concepts
> and purpose, which are independent of the language being used.
>
> Very (I mean VERY :)) briefly, the benefits of OOP are:
>
> * Modularity - keeping related functionality/data together
> * Encapsulation - Limiting access to the data/functionality only to
> what's necessary
> * Extensibility - Making it easy to leverage existing
> data/functionality to create new capability
>
> OOP is not the only way to achieve these goals, but it is a
> reasonable
> way. OOP isn't the solution to every programming problem. There are
> other methods (like functional programming) which may be more
> appropriate depending upon the situation. It's not uncommon for a
> programmer to look at a problem and approach it with OOP just because
> they want to and it can become more cumbersome than solving it a
> different way. On the other hand, sometimes it's worth looking at a
> problem from different angles to see what the pros and cons are.
>
> To me, one of the characteristics about OOP is that it causes me to
> think about the data first before I think about functions. In this
> specific example, we're looking at temperature. Then we think about
> what
> kinds of attributes and functionality are associated with that data.
> For
> temperature, I think the scale representation (F, C, etc) is an
> attribute. As such, I would not use a subclass (or inherited object
> more
> generally) as a way just to get a different representation of the
> same
> data. I would have just one class, Temperature, and then have
> different
> methods to obtain different representations of that temperature.
>
> This will look different using different languages (Smalltalk, C++,
> Python, ...) but since we're in the GNU Smalltalk world for the
> moment,
> I'll toss in such an example. Now this is not perfect and there are
> way
> better Smalltalk programmers than me, so just consider this an
> example
> for study and discussion, and we can pick at the good or the bad. :)
>
> Number subclass: Temperature [
> | tempc tempf |
>
> Temperature class >> new [
> ^self error: 'Use setC: or setF: to construct a Temperature'
> ]
>
> Temperature class >> setC: tc [
> ^(super new) setC: tc
> ]
>
> Temperature class >> setF: tf [
> ^(super new) setF: tf
> ]
>
> setC: tc [
> tempc := tc.
> tempf := (tc * 9.0/5.0) + 32.0.
> ^self
> ]
>
> setF: tf [
> tempf := tf.
> tempc := (tf - 32) * 5.0/9.0.
> ^self
> ]
>
> asC [
> ^tempc
> ]
>
> asF [
> ^tempf
> ]
> ]
>
> I noticed in the original code there were a couple of issues:
>
> * There was no constructor identified for creating a temperature
> with
> a specific value
> * Celsius and Fahrenheit representations were separate subclasses,
> so
> a different representation meant a different data type, making
> conversion back and forth difficult.
>
> In the above example, since temperature is a number, it inherits from
> Number rather than the high level Object. There an be benefits for
> this
> which are outside of the scope of this email. The construction
> involves
> passing an initial value either in C or F scale. You can also change
> (set new) values in either scale once constructed. These setting
> messages return "self" so that you retain the original object.
> Finally
> there are messages for obtaining the value as C or F.
>
> Some simple example usage:
>
> st> t := Temperature new
> Object: Temperature error: Use setC: or setF: to construct a
> Temperature
> Error(Exception)>>signal (ExcHandling.st:254)
> Error(Exception)>>signal: (ExcHandling.st:264)
> Temperature class(Object)>>error: (SysExcept.st:1416)
> Temperature class>>new (a String:2)
> UndefinedObject>>executeStatements (a String:1)
> nil
> st> t := Temperature setC: 0
> a Temperature
> st> t asC
> 0
> st> t asF
> 32.0
> st> (t setF: 212) asC
> 100.0
> st>
>
> Note there's a difference between "instance messages (methods)" and
> "class messages (methods)". A "class message" operates on the class
> itself (and in Smalltalk, a class itself is just another object). An
> "instance message" operates on an /instance of a class/. In the above
> I
> have defined "setC:" and "setF:" both as class messages (for
> construction) and instance messages (to reset the value of a specific
> temperature object).
>
> Here's a link to the GNU Smalltalk tutorial:
> https://www.gnu.org/software/smalltalk/manual/html_node/Tutorial.html#Tutorial
>
> Enjoy!
>
> Mark
>
> On 1/5/2026 9:46 PM, Duke Normandin wrote:
> > See it here:https://controlc.com/a19d683a
> >
> > Critiques please!
> >
> > My first impression(s) is that it seems a lot more complicated to
> > create the OOP logic to get things done than it is in C, e.g. IMHO
> >
> > Maybe it's because I'm not familiar with the syntax yet. But I got
> > it done - thanks to Divine Intervention - I'm sure!! LOL
Thank you for that detailed example.
But why are you saying first, temperature is an attribute of an object,
and then you are making it the object itself?
For me this looks counter intuitive.
I did not write any code for a decade or more, so I cannot present
a working program to you.
But I think
Object()
temperature: number.
temperature.Celsius?: number
temperature.Fahrenheit?: number
would be more intuitive.
That way you could have myRoom: Object.
myRoom temperature.Celsius?
best regards
Wolfgang Dann
