[Oberon] Oberon for a C++ user.

[Jörg Straube]

Yes. It has nothing to do with unloaded modules. It is a nice example to show the effect of "uninitialized variables".
Jörg

> Am 01.10.2016 um 02:06 schrieb <Aubrey.McIntosh at alumni.utexas.net> <Aubrey.McIntosh at alumni.utexas.net>:
> 
> This snipped compiles under Component Pascal 1.7-rc1, and traps with a nil procedure call.
> 
> MODULE TempProcvar;
> 	
> 	TYPE
> 		ParamProc = PROCEDURE ( p: INTEGER );
> 		
> 	VAR
> 		trouble* : ParamProc;
> 		
> 	PROCEDURE UseProc ( method: ParamProc );
> 	BEGIN
> 		method( 42 )
> 	END UseProc;
> 	
> 	PROCEDURE Doit*;
> 	BEGIN
> 		UseProc (  trouble )
> 	END Doit;
> 	
> END TempProcvar.
> 
> 
> 
>> On Fri, Sep 30, 2016 at 6:11 PM, Chris Burrows <chris at cfbsoftware.com> wrote:
>> > -----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
> 
> 
> 
> -- 
> (email is my preferred communication media)
> Aubrey McIntosh, Ph.D.
> 1502 Devon Circle
> Austin TX 78723-1814
> (512)-348-7401
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161001/2cc16298/attachment.html>