Trouble with anon delegates.

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Tue Jan 16 15:09:53 PST 2007


Pragma wrote:
[snip]
> It would be nice if things so succinct would work as I expected.  
> Instead I have to break all the delegates out into proper class methods, 
> which bloats the code and runs contrary to the whole point of having a 
> parser framework like this.
> 
> 
> The ability to declare *first class* delegates as anonymous and inline 
> like the above is just too tempting to leave alone.  I suppose the only 
> way to have your cake and eat it too is to preserve the stack somehow.  
> Maybe this is a job for stack threads?

Maybe we could get Walter to implement a slight change to such 
delegates: instead of getting the innermost context pointer, they should 
get the outermost possible context pointer that still contains all the 
variables/members used?
So then in your case they would get the 'this' pointer, in nested 
functions they could get the stackframe of the outer function if they 
didn't reference variables local to the inner function, and in member 
functions of (non-static) nested classes they could even contain a copy 
of the 'outer' pointer of the nested class, so only the outer class is 
referenced if that's all that's needed.

I have no idea how difficult this would be to implement, but I think 
this will go a long way towards making delegates more usable.

The only disadvantage would be that the validity of a delegate after a 
function call returns would depend on the code it contains, which may be 
a source of tricky bugs...

An alternative would be the explicit context syntax I somewhere today 
(can't find it anymore :( ). Your example delegate would then look 
something like 'this.{ x = x; }'. Not as pretty, but still much better 
than having to define a new member function for this operator, don't you 
think?


More information about the Digitalmars-d-learn mailing list