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.
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.
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.
-- Michael --
"M. Uli Kusterer" wrote:
> >Better yet, if anyone is brave enough to write an xTalk compiler that can
> >call toolbox routines etc (read: modern day CompileIt!) , we'd all be able to
> >write our compiled apps in xTalk instead of C. Heck, we could write OpenCard
> >in compiled xTalk, wouldn't that be nice =)...
>
> But we'd need real data types then. I don't like the way CompileIt handles
> variable types and I like its way to do record fields even less.
> CompileIt's way how one does typecasting, data typing, record fields and
> arrays is not xTalk-ish enough. So, if we get real arrays, I don't mind.
>
> 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
