On Thursday, Dec 5, 2002, at 02:13 US/Pacific, Michael Melhem wrote:

On Thu, Dec 05, 2002 at 09:29:23AM +0100, Sylvain Wallez wrote:
Ovidiu Predescu wrote:

I think the danger is to have the semantics of these functions
associated with the way the response page is actually sent over the wire.

To reiterate my option, I think sendPageAndWait and
sendPageAndContinue are still the best options. They also provide the
maximum compatibility with the old naming, only sendPage dissapears,
everything else is the same.

Agree. I think the confusion of "sendPageAndContinue" with continuations
came from the fact that the "sendPage" counterpart wasn't semantically
precise enough.

Most people seem to agree that "sendPageAndWait" is a good name. My
english skills tell me that "continue" is a good word as a complementary
to "wait". And since my skills are somewhat limited, it's likely that it
most people will have the same understanding as me :)

So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
being equally-precise and semantically complementary.

Yes I agree (like most) that sendPageAndWait is the best name, because it
implies that flow "waits" here for a response. (even though techinically
this is not true)

+1

The "wait" here is in the context of the of the flow method...its the flow
method that waits..but continue in sendPageAndContinue makes sense only in the
context of the sitemap processing, its the sitemap that continues its
processing. This requires a context change in understanding which I find
confusing (and breaks the wait/continue symmetry). Without this context shift,
one might think its that the flow method that continues - as apposed to waiting.
No, Michael, is not the sitemap that continues the processing. sendPageAndContinue will _temporarily_ pass the control to the sitemap to generate the response. After the response is generated, the control is returned to the control flow script. The "Continue" refers to the fact that the function in which sendPageAndContinue appears will continue to execute, _after_ the response was sent back to the client.

Also, a flow method need not have a "sendPageAndWait". Example:

flow()
{
.....

if (something)
sendPageAndContiue(page1)
else
sendPageAndContiue(page2)
}

so in this case, continue could be interepted as "create continuation" as there
is no "wait" to contrast it with.
It should not be. With the proper documentation (I know, I know ;) things should be clear on the meaning and "Wait" and "Continue" in this context.

So as for sendPageAndContinue, I vote

-0.25 (hmm .. im not totally against it)

Hmmmm.. we could end up disussing semantics forever,
but how about "sendPageAndFinish" ? Thats the only alternative i can think of
at the moment. So one would have:

flow()
{
sendPageAndWait
..
sendPageAndWait
..
sendPageAndFinish
}
"Finish" what? The problem with that is that you could still do things after the page was sent back to the client. Advanced users might want to use this fact to do all sorts of nasty things.

Cheers,
Ovidiu

--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to