<div dir="ltr">Excellent summary by Andreas.<div><br><div>In addition I would like to point out that the motivation of</div><div>moving from Object Oberon's class syntax to the Oberon-2 syntax was to</div><div>avoid many forward references. The other motivation was of course to</div><div>make the syntactical differences smaller by removing additional keywords.</div><div>The overall compiler changes for Oberon-2 were smaller than for </div><div>Object Oberon, if I remember correctly.</div><div><br></div><div>In later Oberon extensions such as BlueBottle and A2 the</div><div>problem with forward references has been solved by </div><div>substantially rewriting the parser but I don't know the details of the</div><div>approach chosen. Having methods nested within a RECORD scope</div><div>was thereby less of a burden in practice and very natural with</div><div>respect to scoping.</div><div><br></div><div>In general, the message records and explicit message dispatching </div><div>as used in the Oberon system proved to be successful and have also</div><div>been used in BlackBox for the visible objects (Views), although BlackBox</div><div>does not use handler procedure variables per object but type bound handlers.</div><div><br></div><div>Class based OOP with method tables instead of message records is more</div><div>efficient because it replaces the message dispatching consisting of cascades </div><div>of nested IFs by a tiny constant time operation. It gives up the</div><div>full flexibility and extensibility, though.</div><div>This OOP style has been used in the "Draw" editor for abstracting from the</div><div>different classes of graphical objects (Rectangles, Curves, etc.). The Draw</div><div>editor was used for drawing board layouts with hundreds or thousands of</div><div>graphical elements and at least at that time the performance gain</div><div>was important.</div><div><br></div><div>- Josef</div><div><br></div></div></div>