[Oberon] Oberon for a C++ user.

[Jörg Straube]

Another aspect of modules.
You tried to make the boundary of modules as static vs OOP as dynamic.

You are right: Modules are static in the sense that they deckare the TYPEs the abstracted assets have.
As Oberon is a type-strict language, every dynamically generated object is of a certain defined (fixed) type.

Oberon modules can also deckare procedures to create those objects dynamically on the fly during run-time. 

Modules combine both notions: The objects they deckare and handle are dynamic (run-time), their types however are static (compile-time).
Remember: a pointer to an object can have different types during run-time. You can check the currently assigned type of the object at run-time with "IS".

Jörg

> Am 05.09.2016 um 13:34 schrieb Lars <noreply at z505.com>:
> 
>> On Tue, January 19, 2016 8:42 pm, Srinivas Nayak wrote:
>> Dear All,
>> 
>> 
>> Reading the trilogy, now I have started to understand Oberon language.
>> Here I am trying to understand the concept of Module and Record little
>> more.
>> 
>> In C++, a Class defines the data fields.
>> So the internal representation of a concept remains hidden inside a
>> Class.
> 
> A record is almost exactly the same as a C struct, or a C++ class. A
> module is similar to a namespace. A module is like a static design time
> class that can't be dynamically created at run time... whereas an object
> in object oriented programming can be created at run time as many times as
> you want. A module is fixed at design time and can't be created using
> code.
> 
> Actually by loading modules into the system you sort of can create them in
> an environment like creating an object, so to learn the concept of a
> module it may be handy to just think of it like file with a namespace to
> its own. i.e. each module is named, such as MyModule, and can be accessed
> like a namespace. It is similar to accessing an objects methods however an
> object can be created at run time and accessed as a variable whereas a
> module is a static text file, not a variable.
> 
> Think of a module like a very limited class that you cannot create more of
> at run time, it's a static item you can only create at design time, just
> like a namespace.
> 
>> In Oberon, a Record defines the data fields.
>> So the internal representation of a concept remains hidden inside a
>> Record.
>> However, a Module (not the Record) selectively exposes what is ?
>> accessible
>> to outsiders. So Record takes care of encapsulation(internal
>> representation of a concept), But Module takes care of
>> abstraction(selectively exposing).
> 
> A module can be thought of as just a place to put things with a name
> space, at design time. An object on the other hand can be spawned at run
> time and placed into a variable.
> 
> The fact that there are all these different terms: class, record, struct,
> object, shows that computing science needs some serious rigor added.  The
> Third Manifesto by Date and Darwen tries to clear up some of the object
> orientation confusion by making suggestions (rude ones, even) about
> differentiating between a class and an object (an object is an instance of
> a class, at run time? whereas the class is the static design time
> definition or contract?).
> 
> The fact that we also have namespaces vs modules (the emperor has new
> clothes?) once again says that maybe computing science needs to be
> revisited and more rigorous terms need to be used instead of all these
> duplicate words for the same thing. There is definitely overlapping
> between what a namespace is, vs a module.  There is overlap between
> records, and structs, and objects, and classes.
> 
> Date and Darwen in the Third Manifesto go further and rename everything
> again.. instead of RECORDS you now have TUPLES.... SETS of TUPLES, ....
> instead of SQL's records, fields, etc. You also have RELATIONS, RELVARS
> (relational variables) and other items.
> 
> They try to add rigor and clarify what OOP really is in their book,
> however they are guilty of the emporer in new clothes too.. they come up
> with their own fancy (posh) terms and add even more language to the mix,
> trying to get rid of the old language and coming up with a new rigorous
> one.
> 
>> 
>> It makes me confusing, if I think encapsulation and abstraction are
>> related to each other and should go hand in hand.
> 
> 
> Then why does C++ have namespaces, and not just classes? Why not get rid
> of namespaces?
> 
> So basically if you are looking for what a module is think of it like a
> file, with a namespace that you can group together functions and items
> in..
> you can put whatever you want into a module file and then access its
> namespace.. using dot notation..
> 
> 
> Remember C++ namespaces? or even plain C has files, and instead of dot
> notation in plain C you go:
> 
> something_function
> 
> You make your own modules/namespaces in plain C by using underscores..
> 
> Example:
> 
> editor_set_text
> 
> editor_get_text
> 
> where editor is your made up namespace or module in C... In plain C
> instead of having built in modules or namespaces, people just used
> underscores to separate things.. you prefix sometimes your plain C
> functions with a repetitive word, with an underscore instead of dot
> notation.
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon