[Oberon] Oberon for a C++ user.

[Jörg Straube]

Chris

Here a possble example that might cause issues:

MODULE Figure;
TYPE
  DrawProc = PROCEDURE;
  Figure = POINTER TO FigureDesc;
  FigureDesc = RECORD
    next: Figure;
    draw: DrawProc
  END;
VAR list: Figure;
PROCEDURE Init(d: DrawProc)
  VAR f: Figure;
  BEGIN
    NEW(f); f.next := list; list := f;
    f.draw := d
  END Init;
BEGIN list:= NIL END Figure.

MODULE Square;
IMPORT Figure;
PROCEDURE DrawSquare;
  BEGIN (* do what ever you
    need to do to draw a square *)
  END DrawSquare
BEGIN
  Figure.Init(DrawSquare)
END Square.

Now you could run Square and unload Square. The list in Figure has a reference to unloaded code.

Jörg

Am 01.10.2016 um 01:11 schrieb Chris Burrows <chris at cfbsoftware.com>:

>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Stéphane Aulery
>> Sent: Friday, 30 September 2016 6:19 AM
>> To: ETH Oberon and related systems
>> Subject: Re: [Oberon] Oberon for a C++ user.
>> 
>>> 
>>> I wonder if there is a way out.  Can this problem be solved within
>> the Oberon-1 framework?
>> 
>> What you say is surprising. There are probably a good reason to
>> dismiss this problem. Anybody kwnow why please?
>> 
> 
> I'd like to see actual example code that illustrates the problem as I am not
> convinced it is a problem - at least not with the latest version of Oberon. 
> As Srivas pointed out, e.g. in Project Oberon, if you want to assign an
> external procedure to a procedure variable, or you want to reference an
> external procedure variable you have to import the module that contains that
> procedure / procedure variable. If you have imported that module you can't
> unload it until the importing module is unloaded first. 
> 
> Oberon-2 does have additional object-oriented features. Maybe they cause an
> issue when mixed with the use of procedure variables? Procedure Varaiables
> might have been left in the language in the transition from original Oberon
> to Oberon-2 simply to avoid breaking backward-compatibility. It is likely
> there is no *need* to use procedure variables if you have these additional
> features. This is supported by the following quote from Hanspeter
> Mossenbock's book 'Object-Oriented Programming in Oberon-2':
> 
> "Dynamic binding has also been known for a long time in the form of
> procedure variables. The activation of a procedure variable causes the
> invocation of the procedure contained in it at run time. Working with
> procedure variables, however, is troublesome and error-prone, while dynamic
> binding in object-oriented languages represents an elegant and reliable
> solution."
> 
> It is also significant to note that Procedure Variables are documented as
> 'deprecated' in the .NET version of Component Pascal (the Oberon-2
> superset). 
> 
> Regards,
> Chris
> 
> Chris Burrows
> CFB Software
> http://www.astrobe.com
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon