<div class="gmail_quote">On Wed, Feb 4, 2009 at 5:42 PM, Lukas Renggli <span dir="ltr">&lt;<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
&gt; I don&#39;t want a continuation framework. I want a continuation implementation<br>
&gt; that isn&#39;t implemented only to work in the current implementation of Flow.<br>
&gt; Particularly if Gemstone is doing VM modifications to make this work, it<br>
&gt; would be nice to have an implementation done properly the first time so we<br>
&gt; have some flexibility.<br>
<br>
</div>Again, WAPartialContinuation is within a platform specific package.<br>
The only user is a platform specific method and a the platform<br>
specific tests. Gemstone, VASt, GST, Dolphin, ... will use their own<br>
implementation if they decide to support Seaside-Flow. Forcing more<br>
flexibility does not help other platforms, it will only make porting<br>
harder when we start to use this functionality.<br>
</blockquote><div><br></div></div>It is probably a lot easier for Gemstone to allow their implementation to support a different marker on evaluation if they implement it that way from the start. I am simply raising the possibility that this flexibility is desirable so they can evaluate how difficult it is to support. Otherwise, they may simply have implemented something to the informal spec created by the tests you wrote.<br>
<br>Julian<br>