[Oberon] Oberon for a C++ user.

Lars noreply at z505.com
Tue Sep 27 06:46:29 CEST 2016


On Thu, September 22, 2016 10:52 pm, Jörg Straube wrote:
> Lars
>
>
> Dynamic vs static is perhaps not the best distinction of modules vs
> objects. I try to make an analogon.
> - Modules can be seen as car manufacturer.
> - Objects are the cars.

As you know, I'm no fan of Analogies, like Dijkstra, however I sin and use
them myself sometimes.

A class, can be defined at design time like a module..but once the class 
created (memory allocated on heap) it becomes an object (object is an
instance of class? according to Date and Darwen in Third Manifesto). So a
class definition, is very similar to a module definition (module file),
except one cannot dynamically create modules at run time.  One may be able
to dynamically load a module in an oberon system, which is interesting,
but still not the same as allocating memory in a program on the heap for
one.

Why even refer to analogies when one can describe exactly what a module is
and what it isn't:

What is is not: an item that can be allocated at run time, it is only
typed out as a definition at design time. That's what I meant by static
because the module is not dynamically created on the heap.

A class is like a static definition of an object, where the object can be
dynamically created (allocated) at run time.  An object that is on the
stack is still allocated, just when the program begins.  When is a module
ever allocated?  It's compiled, but not so much allocated..

Again why use analogies when we can talk directly about what an object is,
and what it is not, and what a module is, and what it is not...

Time to sin:
A car manufacturer has definitions (drawings) of the car. This is like an
object definition at the top of the source file (class). Once the factory
produces the car (object) from the design (class) papers, a new instance
of the car is allocated (steel is taken from the earth, along with
plastics and foam for seats).

F*ck analogies! But that's as close as I can think of one... a class
definition is very similar to the drawings with all the restrictions,
specifications of the car. A module is similar to a class definition but
instead of creating a module on the heap at run time, the module is
compiled and generates a design time unit to be used by the programmer.

An interesting thought: if one were to make a module allocated at run time
would this offer anything useful or different than an object being
allocated? Or would we reinvent object oriented programming if modules
could be allocated on the heap?  If we just reinvented objects, now we
know exactly what modules are: design time objects without any heap
allocation at run time.


More information about the Oberon mailing list