On Monday, February 9, 2004, at 10:35 AM, [EMAIL PROTECTED] wrote:



What is the argument against the xTalk messaging model?



Richard,


In most any other dev environment, the only "messages" your app gets are mouse and keyboard events, and possibly network events/messages -- otherwise you are in control of everything else, from what gets drawn on the screen to what user interaction occurs. If there's a bug, there's a good (better) chance it's your problem, and you can usually track it down (modulo problems with whatever framework you might be using).

In RR though, everything's a message, and every piece of code is written in response to literally hundreds of different messages. And this fact that you're one step removed from the actual user means that it's incumbent on RR to ensure that the messages it passes are correct and complete, and in the right context.

That said, I can think of at least four problems that I've seen with the messaging model (which I happen to like by the way):

1) There is no convention for whether one needs to pass messages up to the system. For example,

on openCard
   ...do my stuff...
   pass openCard
end openCard

What impact, if any does passing or not passing openCard (or any other message) to the system have?

2) It's hard to guarantee the message passing context.

on someCommonFunction
   send "foo" to this stack
end someCommonFunction

Sometimes the only way to guarantee that this gets sent to the right stack is to make sure the "this" stack is physically frontmost.

3) The messaging model does not always work correctly. And it sometimes works differently depending on where the code resides.

For example, correctness: I've been adding drag and drop to my app, and very often neither dragEnd nor dragLeave are called. It's probably a bug, but it isn't the only messaging bug I've seen.

As for "works differently": "on drag..." handlers work differently if they're in a control script vs a card script vs a stack script. That shouldn't be the case.

4) Race conditions.

I've seen cases where multiple "dragMove" messages get fired before my "dragEnter" handler completes. This caused all sorts of havoc with my code. And without a semaphore mechanism built-in to the language it's impossible to know if I've solved the problem, or whether it will crop up again on a faster or different machine.

Best,
-- Frank

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to