[Seaside-dev] Re: thoughts on partial continuations

[Julian Fitzell]

And on a related note (not to distract from the original question), I don't
think WAPartialContinuation is as flexible as I would like; it's not quite
the power tool it could be. I'd like to be able to specify whether or not to
unwind to the marker (or to a different marker) when evaluating. I also
think it would be nice to be able to have an interface for evaluating and
creating where you can specify the context directly. The version that takes
a compiled method marker could be implemented on top of that.

I know Dale has just got all his partial continuation tests passing. Will
your implementation allow some more flexibility here Dale or is that a big
pain?

Julian

On Wed, Feb 4, 2009 at 1:40 PM, Julian Fitzell <jfitzell at gmail.com> wrote:

> It occurs to me that there is still a problem with our #call:
> implementation.
>
> We are using partial continuations, which is great, but we are still using
> an exception to signal the end of callback processing. Signaling an
> exception results the callback contexts being unwound and #ensure: blocks in
> the callback being triggered. This is why WAClosureFunctionalTest doesn't
> really make sense.
>
> I noticed this because I noticed that WAComponent>>filterWith:during: did
> not use an #ensure: to remove the filter. I was going to change that and
> move the method to WARequestContext but realized that I can't do that and
> have the method work properly with #call:
>
> So it seems to me that what we should be doing on a #call: is saving the
> partial continuation for the callback and then throwing those contexts away.
> One option would be to simply capture a full continuation before doing the
> callback but this requires a hook at that point again (which I know Lukas is
> strongly against). The only other solution I can think of is to create a
> new, empty PartialContinuation and then evaluate it with the same marker
> that we used to create the other continuation (ie. the
> #evaluateWithArgument: method). This effectively results in throwing away
> the callback contexts and returning as if the callback completed.
> #evaluateWithArgument: would then signal the exception.
>
> Does this make any sense?
>
> Julian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090204/e61ad4c9/attachment.htm