----- Original Message -----
From: "Kerry Thompson" <[EMAIL PROTECTED]>
>
> I stop short of saying it undermines Lingo's credibility, though. It's a
> known issue, with a known workaround, and just about every scripting
> language I've used has issues like this. Lingo remains a powerful and
> flexible language, albeit with some quirks. After all, that's what they
> pay us those big bucks for ^_^
You mean we can get big bucks for this now? ;-)
Actually, I do think it undermines Lingo's credibility, to a greater or
lesser extent, depending on how you look at it. As you can probably tell, I
like to know how things work, so when I write some code I know it's going to
do what I expect it to do. I don't like lots of things being left undefined,
just because the Macromedia engineers are too lazy to address what is
clearly a bug, so they do a Microsoft a re-label it as a feature.
Sorry, but in this case it's not acceptable, and it can seriously complicate
what should otherwise be simple code. Scripting languages are for exactly
that - writing simple elegant code that reads easily. They are not for
writing mammoth chunks of code that explicitly work around every possible
bug-causing case - the language itself is by design, supposed to negate the
need for all that.
You also made the point that we should test for an empty string before
passing it to value(), but I don't see why that should be necessary either.
Again this comes down the the amount of work we are expected to do in our
scripts - really that work should be delegated the the built-in functions,
so something like value("") should always return a known value, it doesn't
matter what, as long as it is consistent. I don't mind the return value
being undefined if the input is not a string, but an empty string is still a
string, so it's well within the function's working specification.
[snip]
> That corresponds with my experience. I believe I mentioned that I found
> the problem in a function call. This is way, way oversimplified, but it
> was essentially this:
>
> x = someFunction()
> if x = FALSE then
> -- do something
> else
> -- do something else
> end if
>
> on someFunction
> --do something
> --but don't return anything
> End
Ah, so rather than returning VOID it actually doesn't return anything -
that's a bit different. You are basically returning an undefined value,
which may or may not be VOID. Having said that, I believe Lingo does
normally put a VOID in as the return value for you, which is really what it
should do to make everything nice & robust - no-one want's to deal with
undefined's in a scripting language, which is why we have VOID in the first
place.
Anyway, if that is where the problem is creeping in, there is still no need
for dirty VOIDs the be handled incorrectly.
- Robert
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL
PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping
with programming Lingo. Thanks!]
