>It will be very big -- something on the order of ten to twenty times
>faster, unless you've got some _great_ optimizer -- i.e., one far better
>than I've seen!
Doesn't OTVar keep its values as some preferred value? Then there shouldn't
be that much of a problem. Just a couple of branches more.
>Better would be to just tell users "you may safely ignore this command".
>
>You'll have people even more confused with documented-yet-undocumented
>commands.
It's just not xTalk-like. That is, I'd hate to see this as part of an xTalk
standard. I.e. it should be like the Layer Manager. Available but not
recommended and not supported. We could put it into an "Advanced Features &
Techniques" chapter of the docs with a disclaimer in front of this like
"Use at your own risk". OK?
>Requires more code and one or more passes through the source to do this.
So what? Compilation happens once, this shouldn't be a problem.
CodeWarrior also makes several passes over the code to optimize it, We'd
just do the same. for testing, you can use one-pass compilation, and then
you can activate optimizations.
>True. But I'd prefer "real" for reals, and "integer" for integers.
>Otherwise, people would get confused ("but an integer IS a number--why
>seperate?!"). This way, they'd know that one was intended for decimals and
>one for integers. Or maybe "decimal" would be a better type name.
I think decimal might work, although people might think that's only the
part behind the comma. "Real" would work for mathematicians, but no
computer stuff like "float" or "double".
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
