At 9:33 PM +0100 on 12/2/99, M. Uli Kusterer wrote:
>>These will become HORRENDUS statements, and I'm in favor of banning this
>>with an error message along the lines of "You dog can script with better
>>style.", or just a long stream of profanity.
>
>Anthony,
>
> yeah, it will require some coding. Although it *should* be possible.
Yeh, possible. But I'd probably just put out a warning message about my ded
pet salamander being able to program better, and run the script as if each
line were a "do" command.
The present architecture will not allow it. The new architecture will not
either. And I don't plan on taking the (I'm guessing here) 20+% speed hit
on _all_ scripts to allow it.
Interpreter converts all variables and temporaries to a number. This number
is used as an index into an array. NullCPU does not know and does not care
about the name of the variables, and thus can't handle this.
The only way I could see handling it is the allocate another variable. And
that is just bad. It would mean reallocating the variable list if it is a
new variable. It would involve some serious hackery to the compilation of
the 'do' command, such as variable remapping [ouch!].
All in all, I think the do command, the send command, and any run-time
variable naming should be left in the scrap heap of history.
>but
>there are better solutions than generating such variables. Usually people
>use this to emulate arrays, so we'd best just give them something like
>that. I'm in favor of associative arrays like MC has (with a hash lookup,
>of course), but with a syntax that looks more like properties.
I don't mind arrays -- not to hard to handle. And if you REALLY want
runtime-named variables, you can use perl-like hashes to fake them.
