Re (3): [Oberon] Win32 Plugin Oberon, status report II

Edgar at Edgar at
Tue Mar 18 21:14:13 CET 2003

John Drake <jmdrake_98 at> wrote:
> > I feel that delegates make sense (For more on
> > delegates have a look at C#).
> You're probably right on that.  Like I said I can
> see how this adds flexibility.  I wasn't aware
> C# had something like that.  But I'm still not
> sure how definining a method and assigning it
> to a procedure variable in Active Oberon is any
> different than defining a procedure and 
> assigning it to a procedure variable in 
> Oberon-1.
Perhaps you could simulate it (Wasn't there a discussion with Ulrich :-?)
The difference is in assignment compatibility I guess. With delegates
prodecures with 'different' signatures are compatible because the implicit
object parameter a method has isn't compared so you have more flexibility.

> > BTW my first problem came with you AosFS. It seems
> > like PluginOberon.Files
> > and Native.Files have some differences.
> > If you are interested I could give you some details.
> Yes.  I would certainly be interested.
In AosFS.Mod you sent me:
  Rider* = RECORD (Files.Rider);	(** not shareable between multiple processes *)
    (* the rider must be a record, otherwise the Oberon text system will not work *)
	(** private fields for implementors *)
	apos*, bpos*: LONGINT;
	hint*: Hint;
	file*: File;
but in Native Files.Rider already has apos, bpos, hint and even file, but a
'Files.File' naturally IIRC. So there is a conflict.
I'm not sure yet about the best fix.

> without delegates, though I think the port is
> more work than either of us first thought.
Agreed. I didn't expect the delegates problem. But even Patrik Reali was surprised.
So perhaps I missed something.

> taking a look at the DAV code again.  You're on
> version 7 right?  Module WebDAV.Mod uses delegates
> for the objects ChunkedOutStream and 
> ChunkedInStream.
That's where the problem appeared for me.

> Another thought that this brings mind another idea
> I've been kicking around for awhile.  I call it
> the "convergent Oberon project".
Here I see some problems. But no time to lay them down this evening.

Cheers, Edgar
edgar at                  ""
""    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein

More information about the Oberon mailing list