Oberon criticisms

[William James]

For the 80s Oberon-2 is/was a great programming language.
Obviously, there have been various attempts to cure some
shortcomings (e.g. Blackbox Component Pascal).
However what bothers me most after reading some Oberon
source-code and Mössenböcks "OOP in Oberon-2" are
(1) Split of interfaces into event-(records) and method-interfaces -
since type safety is lost and interface-specification suffers.
Compare this e.g. with bi-directional interfaces in TinyOS's
Java's Swing event system, though I think it's too verbose.
(fixed in Oberon for .net ?)
(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.

How important are these two shortcomings?

[Ondrej Hrabal]

Post by William James

For the 80s Oberon-2 is/was a great programming language.
Obviously, there have been various attempts to cure some
shortcomings (e.g. Blackbox Component Pascal).
However what bothers me most after reading some Oberon
source-code and Mössenböcks "OOP in Oberon-2" are
(1) Split of interfaces into event-(records) and method-interfaces -
since type safety is lost and interface-specification suffers.
Compare this e.g. with bi-directional interfaces in TinyOS's
Java's Swing event system, though I think it's too verbose.
(fixed in Oberon for .net ?)
(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.

How important are these two shortcomings?

1) It's not a problem of the language itself. It's a problem of the
libraries you use (or write on your own). Yes, the original Oberon
language lacked type-bound procedures, so it rested on dynamic type
tests too much. With Oberon-2 one can define and use full-fledged
statically checked object interfaces.
To make the event-handling interfaces more enticing I'd welcome a
mechanism similar to Java's "anonymous inner classes". These could
replace procedure types.

2) I totally agree. This is the most important feature, that not only
Oberon, but also all mainstream languages (except the new Java 1.5)
lack.

Regards, Andy

[Chris Burrows]

Post by Ondrej Hrabal

(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.

2) I totally agree. This is the most important feature, that not only
Oberon, but also all mainstream languages (except the new Java 1.5)
lack.

Generics are also reported to be on their way for a future release of
Component Pascal for both .NET and JVM.

http://groups.yahoo.com/group/GPCP

Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[Ondrej Hrabal]

Post by Chris Burrows
Generics are also reported to be on their way for a future release of
Component Pascal for both .NET and JVM.
http://groups.yahoo.com/group/GPCP
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

It would be great, just as the second promised feature - interfaces
with contracts. I don't know what's the progress. The proposal was
written back in 1997 and Clemens Szyperski also mentions it in his
Component Software.
The proposal can be found at:

research.microsoft.com/users/cszypers/pub/jmlc97.zip

Regards, Andy

[jmdrake]

Post by Ondrej Hrabal

Post by William James

(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.

How important are these two shortcomings?

1) It's not a problem of the language itself. It's a problem of the
libraries you use (or write on your own). Yes, the original Oberon
language lacked type-bound procedures, so it rested on dynamic type
tests too much. With Oberon-2 one can define and use full-fledged
statically checked object interfaces.
To make the event-handling interfaces more enticing I'd welcome a
mechanism similar to Java's "anonymous inner classes". These could
replace procedure types.
2) I totally agree. This is the most important feature, that not only
Oberon, but also all mainstream languages (except the new Java 1.5)
lack.
Regards, Andy

Actually #2 is really not a problem of the language itself either.
You can implement data structure libraries fine without "generics"
or "templates". In the OOC project they created a nice ADT library
that I've used under System 3 (after removing a few compiler
extentions). I'll post some sample code.

Regards,

John M. Drake

[Ondrej Hrabal]

Post by jmdrake

Post by Ondrej Hrabal

Post by William James

(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.

How important are these two shortcomings?

1) It's not a problem of the language itself. It's a problem of the
libraries you use (or write on your own). Yes, the original Oberon
language lacked type-bound procedures, so it rested on dynamic type
tests too much. With Oberon-2 one can define and use full-fledged
statically checked object interfaces.
To make the event-handling interfaces more enticing I'd welcome a
mechanism similar to Java's "anonymous inner classes". These could
replace procedure types.
2) I totally agree. This is the most important feature, that not only
Oberon, but also all mainstream languages (except the new Java 1.5)
lack.
Regards, Andy

Actually #2 is really not a problem of the language itself either.
You can implement data structure libraries fine without "generics"
or "templates". In the OOC project they created a nice ADT library
that I've used under System 3 (after removing a few compiler
extentions). I'll post some sample code.
Regards,
John M. Drake

Anyway, with parametric polymorphism in place, the library would be even nicer.

Andy

[Michael van Acken]

Post by Ondrej Hrabal
[...]

Post by jmdrake
Actually #2 is really not a problem of the language itself either.
You can implement data structure libraries fine without "generics"
or "templates". In the OOC project they created a nice ADT library
that I've used under System 3 (after removing a few compiler
extentions). I'll post some sample code.
Regards,
John M. Drake

Anyway, with parametric polymorphism in place, the library would be even nicer.

Parametric types, similar to generics in Java, are supported by OOC.
For details, see

http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html?rev=1.2#SEC19

The library modules ADT:ArrayList and ADT:Dictionary have been
converted to use type parameters.

-- mva

[Ondrej Hrabal]

Post by Michael van Acken
Parametric types, similar to generics in Java, are supported by OOC.
For details, see
http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html?rev=1.2#SEC19
The library modules ADT:ArrayList and ADT:Dictionary have been
converted to use type parameters.
-- mva

So the new version of OOC supports bounded parametric polymorphism and
exceptions. Great! I didn't know this.

Thanks

Andy

[August]

Lightweight parametric polymorphism for Oberon-2 is disscussed in
http://sky.fit.qut.edu.au/~roe/papers/JMLC97.ps.gz

-- August

Post by William James

For the 80s Oberon-2 is/was a great programming language.
Obviously, there have been various attempts to cure some
shortcomings (e.g. Blackbox Component Pascal).
However what bothers me most after reading some Oberon
source-code and Mössenböcks "OOP in Oberon-2" are
(1) Split of interfaces into event-(records) and method-interfaces -
since type safety is lost and interface-specification suffers.
Compare this e.g. with bi-directional interfaces in TinyOS's
Java's Swing event system, though I think it's too verbose.
(fixed in Oberon for .net ?)
(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.

How important are these two shortcomings?