[Oberon] Oberon for a C++ user.

[Jörg Straube]

Lars

If you look at a compilation unit in Oberon (called module), the whole module (in addition to a procedure) defines a sort of contract.
The programmer decides (by syntactically adding a * to a constant, procedure or variable) what external users of the module can do and see.

A variable local to the module can become visible to the outside by exporting it. You call this "global", I rather prefer the word "visible and module-owned".
In former Oberon this export of variables was read/write. This was a problem as an external write to a module-owned variable could indeed violate some module internal rules/contracts.
This is the reason why in Oberon-07 exported variables are read-only. If you want to make them modifiable, the module has to provide an (exported) procedure. This procedure takes care of possible module-internal contracts on this visible variable.

Jörg

> Am 09.11.2016 um 06:56 schrieb Lars <noreply at z505.com>:
> 
> On Tue, November 8, 2016 4:33 am, Bob Walkden wrote:
>>> Any idea why they did not choose to use the delphi style system, where
>>> information is passed in through a parameter to the procedure?
>> 
>> Communication is 2-way between the controls and the model.
>> 
>> 
> 
> Well I'll have to try it out more, but I don't see why you can't do two
> way communication using parameters too. I just thought that using
> parameters wherever possible was the ideal programming practice since you
> are dealing with local variables, not globals; and having a parameter list
> to work with means you have a contract: you can inspect the parameters in
> the documentation and it is like a contract you work with. With globals,
> pretty much anything goes, and there is no documented contract telling you
> what information is available in the procedure.
> 
> Once again, though, I'll have to work with component pascal more, as I
> could be missing out on something that blackbox has which is better than
> delphi's system. I guess I'm just stuck in my old ways where I like seeing
> a parameter list of items to inspect, as a contract, sort of a
> documentation of what can be done in a procedure.  With globals in some
> other unit, its difficult to know what all is available to inspect as
> there is no parameter list to work with. For example, let's say a widget
> informs you of the x, and y positions of the mouse coordinates. In delphi,
> x, and y are passed in as parameters.  In blackbox? This is where I get
> lost and don't understand the design choice: the x and y coordinates have
> to be inspected by accessing some global variable in some other module? 
> To me, globals just seems less academic, and more "shoot yourself in the
> foot" because it is a global, not a local! But again, before I criticise,
> I'll have to use blackbox more. It's just my first instinct and gut
> reaction.
> 
> 
>> It comes from academia, where the brief is not to copy but to innovate
>> and improve.
>> 
>> It encourages layering in the module structure. The interface is based on
>> mvc and described in the BB documentation.
>> 
>> My practice has been to develop the model components with a dialog module
>> separating them from the UI controls.
> 
> What would be an example of a model component...
> 
> When you say component, it reminds me of a gui widget component. Do you
> mean by component, a extended record? a module? Or something else... The
> issue is multiple terms:... object, component, module, record.. So I do
> not know what a component refers to in all cases. In delphi, a component
> refers usually to a gui widget or a visual component that is dropped on a
> form, rather than pure code itself.
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon