[Oberon] Oberon for a C++ user.

[Douglas G. Danforth]

Lars,
Every access to modules exported quantities are "qualified" by the 
module name.
So that there is not a "name space" for each module but rather a global 
name space
that holds all possible exported quantities.  I use the word quantity 
since one can
export a CONST c*, or TYPE t*, a VAR v*, or PROCEDURE p* as
mod.c, mod.t, mod.v, mod.p where "mod" is the name of the module.
-Doug Danforth

On 9/28/2016 12:59 PM, Lars wrote:
> On Tue, September 27, 2016 9:41 am, Srinivas Nayak wrote:
>> And Module is the feature in Oberon that supports Encapsulation and
>> Abstraction, not Record.
> The question to ask, is what do Namespaces in C++ offer, as I have always
> thought of a module like a namespace per file. i.e. each module is a
> namespace.  However sometimes direct comparison between two things is not
> entirely accurate, i.e. namespaces are not exactly the same as modules
>
> I just noticed that no where in your messages did you really link
> namespaces to oberon modules. Since the title is oberon for a c++  user I
> thought it would be handy to compare namespaces in C++, to modules in
> Oberon, since I have always found them similar
>
> Do namespaces in C++ support encapsulation and abstraction?  I have always
> thought of modules as separating code into different files so that it is
> not one large long standard pascal program in a single file.  In plain C
> you could separate code into different source files, however it all had a
> single global namespace so procedure_one would conflict with procedure_one
> in another file if it was part of the same program, so you used a
> namespace prefix per each function:
>
> module1_procedure1
> module2_procedure2
>
> where module1 and module2 are the namespaces respectively. I.e. plain c
> did not have actual namespace feature, you just created the feature
> yourself using  underscores.
>
> Sorry I'm trying to explain this without using complex confusing lingo
> such as abstraction, encapsulation... The way I see it, is just
> "separating concerns". I believe N. Wirth has described modules somewhere
> as separating concerns also.
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>