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

[Edgar at EdgarSchwarz.de]

John Drake <jmdrake_98 at yahoo.com> 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;
  END;
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 edgarschwarz.de                  "http://www.edgarschwarz.de"
"http://www.edgar-schwarz.de/forum/oberon"    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein