The paradigm of containers and self-referenced names
Dar Scott
dsc at swcp.com
Wed Mar 23 12:36:45 EST 2005
On Mar 23, 2005, at 9:58 AM, Ken Ray wrote:
>> The meaning of a name in Revolution--container or literal--depends on
>> its usage beyond a particular instance.
>
> I think that if Rev were modified so that it would not accept unquoted
> strings to be assigned to variables we'd be in a much better place,
> and it
> wouldn't give aid to "sloppy" (IMHO) programming.
(I'm not sure why the "to be assigned to variables" qualification. I
assume you mean anywhere.)
I see merit to this. It would not break my scripts, but I suspect it
will break a lot of scripts. I would not whine if this happened.
However, there might be a compromise that preserves some of the
heritage:
1
One possibility might be as you state, but add a new declaration,
perhaps like this...
token apple
...which is virtually equivalent to...
constant apple = "apple"
...but might take up less memory.
2
Another might be a great simplification of the rule that determines
which it is. Along with reliable highly-differentiated colorization,
too! I think this would respect the heritage.
This would break very few scripts and those it does break are probably
in trouble.
This might be the friendliest to the heritage.
3
Another might be that the initial value of every container is its name
and there are no unquoted literals. This is gentle to both
traditionalists and crossover programmers. Some crossover programmers
make this assumption at first.
That would break some of my sloppy scripts and I imagine would break
other folk's. This would be mostly in the initial value of a container
that accumulates values as a loop executes.
Some scripts would have to add...
local newList = ""
.. or ...
put empty into newList
... at the top.
Even though this would break some of my scripts, I would be fine with
this.
This would break a few traditional scripts in places that depend on
name/literal differentiation in strange ways. Those may be flawed
anyway, but I'm not sure.
4
Other?
Dar Scott
More information about the use-livecode
mailing list