On Sunday, February 8, 2004, at 07:29 PM, Frank Leahy wrote:
>Removing exceptions can simplify xTalk and enhance its power.
You mean try/catch/end try? It might simplify things, but it sure won't enhance anybody's power. There are numerous places that common functions can fail in xTalk (e.g. set the fileName of an image to an alias file -- oops) Since xTalk has no consistent failure reporting mechanism, exceptions are really the only reasonable way to handle exceptional conditions without having tons of if statements littered throughout your code. (What, you mean you don't handle error conditions? Shame on you :-)
My error. Wrong word.
I mean all the places where the semantics has an "except" or "but not" or "is limited to" or "must already" or similar.
For example, a key in an array cannot contain a NUL character. Also, the second delimiter of combine cannot be NUL. (The TD also disallows others.)
Can I use an expression for a property name? Is the answer yes, no or 'um, that's a little complicated'?
I do use 'try', even though I write perfect code. ;-) Of 'catch' and 'finally' can you remember which ones are optional and which ones are required?
You can use an array variable as an parameter in a function application. You can even return it as the value of the function if it is put directly into a variable. But you cannot return an array from a function application that is an expression that is a parameter for another function. eg: put fixArray( fixArray( arrayX ) ) into arrayY
If I 'put 2 into x', the variable x might be made for me, but matchText() and decodeBinary() (according to the TD) need the variables to be already created.
This goes on and on.
Dar Scott
end soapbox
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
