Re: frame-local variables weirdness

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> It also has the big limitation that all references to the value must be
>>> specially written to access a specifier.
>> Right, just like right now they're specifically written to access a variable.

> Er, well, isn't the point that that code is in general written to use
> variables, so that's _not_ a burden?

> The nice thing about these magic variables is that you can make
> something frame specific even though the designer of the code didn't
> think of that (he just used an ordinary global variable).

Agreed.  In this sense, specifiers are halfway between frame-local variables
and using frame-parameter: like using frame-parameter they do require the
programmer to expect that the variable is going to be made local to
something, but like frame-local variables they do not require the programmer
to know to what kind of thing it's going to be made local (it can be made
buffer-local, frame-local, window-local, buffer-position-local, ... without
changes to the code).

Maybe a half-way between variables and specifiers would be to declare some
variables as "specifiers": such variables can be read in the usual way (via
symbol-value) and we could probably arange for setq to do something sensible
as well, but let would be ruled out.

Basically, this new proposal is trying to focus on the one issue which
I believe is key: mixing object-local bindings with let-bindings is a source
of pain and bugs.


        Stefan