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