mission critical apps; was Re: cross platform ide

[Richard Gaskin]

Frank Leahy wrote:

> 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.

...requiring you to roll your own for everything else, unless you use an
even-driven framework like the old THINK Class Library, Metrowerks'
PowerPlant, or Apple's Cocoa.

Think of Rev as a precompiled framework.

> 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?

There is no one right way to use "pass".  You can choose to pass system
messages or not as the specifics of the task at hand require.

Passing a message means you can augment the behavior downstream, not passing
means the handling will not be affected by downstream objects.

Having options for solving different problems in different ways is a feature
enjoyed by most languages.

> 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.

Or to use a less ambiguous object reference:

  send "foo" to stack "MyStack"

Having both context-dependent and absolute object references is a feature of
many programming languages.


> 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.

This may be the difference between a language feature and a bug.  If you
have a repeatable recipe for behavior that deviates from the docs then
please submit it to Bugzilla.

All software has bugs.  If CodeWarrior won't compile an API call correctly
it doesn't reflect on the design of the API.


> 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.

The potential for race conditions is not unique to xTalk, but is inherent in
any thread-like system.

If you're having difficulty getting reliable behavior post your code and
lets see what we can do.


All in all, these sound less like the sorts of arguments an IT manager would
offer against xTalk than simply evidence of a learning curve as there is
with any comprehensive framework.

And none of them are unique to xTalk (though the simplicity of the examples
is <g>).

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com