[Oberon] Oberon for a C++ user.

Lars noreply at z505.com
Wed Nov 9 06:56:22 CET 2016


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.



More information about the Oberon mailing list