So far I've counted three +1 votes for reverting back to the old naming convention and providing the following aliases:
sendPage <=> sendPageAndWait (this function provides the blocking functionality, the response is sent, the continuation captured and the script execution stops)
sendPageAndContinue <=> sendPageNoWait (this function sends the response and continues the script execution)
Ugo expressed his -1 on it but I do hope he would change his opinion. Although he's not a committer I do value his opinion ;)
Most of the docs and presentations I've written so far refer to the old naming convention. All the past emails on the mailing list explaining what the control flow is and how it works use the old convention name, with sendPage() being the blocking function, not the pass-through one we currently have. I think is important to maintain this understanding, otherwise we'll end up confusing a lot of people.
Please cast your votes on whether you wish to revert to the old naming convention and providing aliases as described above and in the message cited below.
Best regards,
Ovidiu
On Monday, Dec 9, 2002, at 10:40 US/Pacific, Ovidiu Predescu wrote:
OK, let's wrap up this discussion.
What I'll do is revert to the old naming and at the same time provide some useful aliases for the default functions.
sendPage <=> sendPageAndWait
sendPageAndContinue <=> sendPageNoWait
This means the sendPage() function will also be accessible as sendPageAndWait(), and sendPageAndContinue() will be accessible as sendPageNoWait().
Since in JavaScript functions are objects, if you don't like the default names you can just assign them a new name without any penalty in runtime performance:
var sendPageWithSomeNewIllustrativeName;
sendPageWithSomeNewIllustrativeName = sendPage;
and so on.
I'll make sure in the documentation we mention the above.
I would like us to spend our energy in discussing better things that names (and, ahem, implementing and documenting them). For some reasons discussions on names seem to provide the most heated debates.
We can also split the current functionality of sendPage in two functions as described by Marc and Giacomo, but I'd consider this functionality to be for advanced usages. This should be an alternative API for the much simpler sendPage API, and not a replacement for it. Several people on this list outlined this functionality, let's crystalize these discussions and come up with a good API for it.
Please cast your votes on:
- maintaining the old naming conventions and providing the above aliases for sendPage* functions; here's my +1.
- further discussions on an alternative API for sendPage; here's my +1.
Regards,
Ovidiu
On Monday, Dec 9, 2002, at 00:38 US/Pacific, Christian Haul wrote:
On 08.Dec.2002 -- 03:48 PM, Stefano Mazzocchi wrote:Hmmmm, hmmm, hmmm, ok, ok, what about something radically different like
getUserInputFromScreen(uri)
to replace sendPageAndWait()?
Only that this function returns void which is again misleading. I would expect a function named "get...." to return a value.I'm all with Christopher: revert to "sendPage" and have some ugly name for the special case where no continuation is created. But then we are back to start :-( Splitting it up like Marc suggested would be another option only that 95% will write their own wrapper around this since the natural use is all three together (create id + send page + create continuation). OTOH there would be interesting uses if one could slip in code between create id and send page. Of course we could split it up and provide a convenience function. Chris.--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
