[Oberon] Oberon usage

[Christian Demmer]

Jörg wrote:
>I see Dennis' point but find the Oberon approach - although
>more verbose - clearer. Strong type checking is not possible
>with "write"; the compiler must take the base type of the
>actual parameter to determine the correct write routine per
>parameter and generates code for a certain output pipe.
>In Oberon you have the benefit of checking formal and
>actual parameter types and can decide on your own where
>you want your IO to happen...

So the general approach would be parameter based function dispatch. I
don't see why it should be restricted to basic IO then. What's so
special about it. In a GUI environment the use of string IO is limited
anyway and if things get a bit more complex like styled text, basic
string IO is not enough.

Concerning the general case: parameter based function dispatch. I don't
like it. It makes things hard to read. It's difficult to check locally
what function is really called.

>A word to initialization: We have to distinguish two
>different scenarios: Static and dynamic. You're right:
>Oberon allows the static initialization in the MODULE body.
>As Chris showed briefly in an mail, with this mechanism
>we can initialize MODULE variables to a given value,
>and the client modules can use those pre-initalized
>MODULE variables:
>  center := Point.null 

I see. I was thinking of static initialization.

>But in Oberon the dynamic initialization after a NEW has to
>be coded by hand.

Nothing wrong with it I think. Libraries with complex setups mostly
offer helper procedures which generate and initialize the necessary
objects for you anyway.

My experience is, that these buildin automatic does not scale well
beyond text book examples to real world problems where lots of things
have to be done for setup, so a custom handcoded solution has to be done
anyway.

> That was one of the reasons why Active
>Oberon added the initializer marked with "&".
>This function is automatically called after a NEW and
>initalizes the new variable with a default value.

I believe an important reason for the init function in Active Oberon is
the race condition between the init function and the thread start of an
active object that would occur if initialization is not atomic.

IMHO this is a problem with active objects. I am not sure the "object
equals thread" structure is a good one. I would prefer multithreading
and objects to be orthogonal language features which can stand on their
own if convenient.

Greetings, Christian