[m-dev.] Generating methods for foreign classes

[Peter Ross]

On Fri, May 25, 2001 at 12:34:40PM +0200, Peter Ross wrote:
> On Thu, May 24, 2001 at 04:28:43PM +1000, Fergus Henderson wrote:
> > On 24-May-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > In MLDS the body of Salary would look something like:
> > > 
> > > call(Signature, FunctionRval, yes(ThisRval),
> > > 	[
> > > 		lval(var("s")), 
> > > 		lval(field(no, ThisRval, named_field("state")...)),
> > > 		mem_ref(lval(field(no, ThisRval, named_field("state")...))
> > > 	],
> > > 	[], yes)
> > > 
> > > But the big problem is that I don't know what ThisRval should be.
> > > There doesn't appear to be an rval for "this".  I think it might be
> > > missing from the MLDS actually.
> > 
> > Right.  I think we should add a new lval constructor, called "this" or
> > "self", for "this" in Java/C#, argument 0 in MSIL, and either "this" or
> > "*this" in C++.  I'm not quite sure which is the best thing to use in
> > the C++ case; the MLDS is a bit inconsistent about it and the relevant
> > parts of the code are currently not used, so it's hard to know what
> > will keep things simplest.  Probably we should name the MLDS lval
> > constructor "self" to avoid tying it too strongly to the C++ "this"
> > keyword.
> > 
> I will work on adding a new lval called 'self' on the dotnet-foreign
> branch.  Then use it to generate my code, fix all the bugs then merge
> the 'self' change back onto the main branch.
> 
BTW, shouldn't 'self' be an rval not an lval.  As there is no way that
this can be used as the target of an assignment.

Pete
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------