[Oberon] [Fwd: RE: objects and jewels]
fp at vonck.nl
Sun Feb 24 21:40:34 CET 2013
To wrap it up (spring holidays are coming to an end).
I want to use oberon in an educational setting to program microcontrollers.
The most used platform for starters nowadays is the Arduino. However, the
arduino language, based on Processing which is based on Java, is not an
ideal language to start learning programming. Moreover the underlying
drivers of the arduino are al written in C++ which makes it even harder to
understand (and therefore teach) what goes on under the hood.*
First I tried to mimic the arduino programs as close as possible. I found
out that Arduino is object oriented with dynamic types. For example a
servo is initialized like this servo1.init(1);
Oberon07 does not have dynamic binding of types. Probably for good
reasons. The closest thing to dynamic types is using procedure types,
which renders a statement like this. servo1.init(servo1,1)
I tried to use type extension to create led objects.
Leds are connected to a pin. A pin has a function and the function has
some parameters to be set.
The information about the led object can be recorded in it's attributes,
however, it seems to me that in the microcontroller world this creates a
lot of redundant information. The state of the pins are all registered in
the microcontroller registers. Set and get methods can be directed
directly to the registers and not to the objects. This is my argument why
an object orientation with dynamic types is not necessary for
Maybe you have a better explanation and yes I've read Steps Beyond,
Chapter 14 Oberon-2.
For now I stick to the modular approach.
Every object like Led or Servo gets its own module. In the modules a base
object is defined like a record. State of objects are recorded in
registers which can be accessed through get and set procedures.
I will experiment with procedure types when I want to create an descendend
objects like blinking led, or a two way led.
*This is also true for the so much laureated Lego Next. Java on top of C++
libraries. A very expensive dialectical nightmare.
More information about the Oberon