Ken Ray wrote:
On Sun, 8 Apr 2007 22:16:32 -0700, Mark Wieder wrote:
string that represented a serial number she allowed the engine to
process the equality operator numerically. And gave it values beyond
those it could be expected to handle with a default margin of error.
Actually, Mark, this was her post:
put "09114E715806" = "09114E715806"
So she *did* quote it. I'd agree with you if it weren't quoted, but as
it was, I would expect this to be interpreted as a string and not a
number.
I'm torn between the two opinions. In a way, I agree with Mark. The
flexibility of xtalk allows us to be very lax about variable typing --
we don't really have to do it at all. I believe the engine evaluates
even quoted literals to try to type them. For example, this works:
set the brush to "4"
If the engine were not evaluating the string, this example would fail.
That means that even quoted literals are not always literals if they are
numbers. I think it would be difficult to fix this problem without
severely restricting the flexibility of the engine in general. We would
be forced into pseudo-typing all variables by only using quotation marks
when we really do mean exact literals. That wouldn't necessarily be a
terrible thing, but it would break backward compatibility with
traditional xtalk. The consequences of the engine change could affect
lots more than the single, unique problem we're trying to fix. Here's
another thing that works right now:
put "4/9/2007" is a date
This isn't just a string. It is a string with numbers in it, and Rev has
to evaluate them as such. The character "4" is not the number "4", which
allows Rev to determine that "4/ew/2007" is not a date (an improvement
over HC, which did think "ew" was a date.) If we remove the ability to
parse quoted dates as numbers, then how do you solve the issue where
1/1/2007 becomes an (incorrect) division command?
On the other side, as Richard says, a string should always equal itself.
And in fact, it does, provided you force the engine to evaluate it as a
string. I accomplished this by specifically adding quotation marks
around the variables that contain the so-called "number". Jim points out
that adding a null character does the same thing.
I think the engine performs flawlessly except in this one, narrow
circumstance where there is a single "E" inside a group of numbers. I
would be okay with RR just adding documentation clarifiying the possible
pitfalls of using numerical strings. On the other hand, this behavior
could throw people who weren't expecting it (and it threw me until I
understood what was happening.) On the third hand, I've worked with
numerical strings in Rev/MC for almost 10 years now and this issue has
only occured once. It's a minor issue, though significant to the
developer when it happens.
I guess I'll report it, and let the team figure out the best way to
handle it.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
