what about I/O terms? sendPageBlocking sendPageNonBlocking
or something akin to these? > Sylvain Wallez wrote: >> Michael Melhem wrote: >> >>> On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote: >>> >>> >>>> Marcus Crafter wrote: >>>> >>>>> Hi Troops! >>>>> >>>>> Hope all is well. >>>>> >>>>> I've just checked in BZ#14903 which changes the names of the >>>>> flow sendPage* functions as previously discussed in the 'flow wishlist' >thread. >>>>> >>>>> Unfortunately the change is *not* backwards compatible so please >>>>> be careful and update any flow code you might have locally after >>>>> updating. >>>>> >>>>> The changes are: >>>>> >>>>> sendPage() becomes sendPageAndWait() >>>>> sendPageAndContinue() becomes sendPage() >>>>> >>>>> The last one is the tricky one because the method names are essentially >swapped. >>>>> >>>>> >>>> >>>> Just some thoughts (sorry if this already has been discussed, I may have missed >it) : why >>>> not keeping the "sendPageAndContinue" ? >>>> >>> >>> >>> sendPageAndContinue is precisely the problem, many people were confusing >"Continue" with >>> continuations! >>> >>> >> >> Ah, ok, I understand... but I'm still uncomfortable with having a precise >"sendPageAndWait" >> and an imprecise "sendPage", as inconsistent naming always leads to confusion. >> >> So, last try : what about "sendPageAndReturn" ? > > I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn' that much, but >it's true > that 'sendPage' contains less semantic meaning than 'sendPageAndWait' and therefore >might > become a little confusing at first. It's a little bit semantically unbalanced and >this doesn't > reflect in their functional operation. > > So, let's see, that method is supposed to 'send a page' to the client but is not >going to wait > for the client to come back and continue. So, the real name would be something like > > - sendPageAndDontWait > > but that sucks. > > - sendPageAndReturn > > is nice but only if you understand that the flow layer takes control over the >sitemap and that > 'return' means that you are returning from procedural continuation-based control >(the > flowscript) to declerative request driven control (the sitemap) > > So it does have perfect sense for us, but I'm not sure it does for somebody that >looks at the > flowscript for the first time. > > But I can't come up with anything better because > > - sendPageAndExit > > might be even worse (people might think Cocoon might stop!) > > Any idea? > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > -------------------------------------------------------------------- > > > > --------------------------------------------------------------------- To >unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- "The heights of genius are only measurable by the depths of stupidity." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
