>I thought a lot about this, and I don't see why one couldn't
>"optionally" specify the type of a variable. Once the type
>was declared it would be unable to be used in any other
>context (until we added implicit or explicit conversion),
>but the advantage could be a performance increase for
>operations using that variable.
Michael,
optionally isn't bad to increase performance, but it would also make xTalk
a lot more computer-ish. Also, I think Anthony has done a great job with
OTVar and the speed gain of hard typed variables over OTVar shouldn't be
very big. However, if you really compelled, I propose the following: Make
it an undocumented feature, that is, make it a feature for which we don't
make any promises, and which isn't part of the regression tests.
So, basically this would just be a hack, which would let professionals
increase the speed, but wouldn't disturb newbies. It'd be part of the
"hacker myth" of advanced scripters. Of course, undocumented is only
officially. We would include a tech note which tells our users about this
feature, and that it might go away any time.
But honestly, I'd prefer if xTalk was smart enough to determine the
variable's type from the way it is used, like CompileIt tries for HyperTalk
scripts. This could work by simply keeping track of how a variable is used
when compiling and then using the type used most as the default type for
the variable, doing temporary conversions on other occasions.
>I don't see any reason we would need to change the xTalk
>language at all, except adding the syntax to add new
>data types at runtime. Consider that fields, stacks, and
>cards are already just different data types in the OT
>environment. These data types were somehow loaded at
>bootup and the keywords for manipulating them were
>somehow added to the command and property list.
Pluggable code is OK, but please no plug-ins crowding xTalk's namespace.
People who can recompile OpenCard may add other types and distribute them,
and we'll make it easy to add a new function using a technique like the
function registry in Interpreter. Also, such plug-ins get lost too easily
and then the users will get script errors.
>The system I envisioned were of binary plugin modules
>that contained data types and the associated manipulation
>routines. Perhaps these were compiled as "static" or
>"shared" libraries with the OT interpreter executable.
Static libraries. See above for the reasons.
One more thing: Have a non-programmer devise the names of the data types.
Most non-programmers don't find "string" very natural, they prefer "text"
etc. "float" should be "number", for example, while "integer" is used for
integer numbers etc.
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
