Variable instances (Re: Trace on Variable assignment)
Ulf Wiger
etxuwig@REDACTED
Fri Nov 3 13:00:35 CET 2000
On Fri, 3 Nov 2000, Ulf Wiger wrote:
>X = foo(...), % [0] is implicit
>X[1] = bar(X),
>...
>
>or perhaps
>
>X = foo(...), % \0 is implicit
>X\1 = bar(X),
>...
>
>
>would allow trace on "changes" to a variable, and also introduce a
>standard way of describing something that occurs frequently in
>most Erlang code I've seen.
>
>/Uffe
Since I posted this without thinking much, I paused and thought about
it afterwards.
One common source of bugs (and very hard to find) is when "changing" a
variable and forgetting to pass the latest instance. An example from
application_controller.erl:
handle_call({unload_application, AppName}, _From, S) ->
case keysearch(AppName, 1, S#state.running) of
{value, _} -> {reply, {error, {running, AppName}}, S};
false ->
case get_loaded(AppName) of
{true, _} ->
NewS = unload(AppName, S),
cntrl(AppName, S,
{ac_application_unloaded, AppName}),
{reply, ok, NewS};
Now it possibly won't matter in this case that cntrl/3 is called
with S instead of NewS (cntrl will look at S#state.control, which
isn't changed by unload/2), but I'd say it'd be a lot better to pass
NewS anyway to avoid confusion.
If the function could be rewritten as:
handle_call({unload_application, AppName}, _From, S) ->
case keysearch(AppName, 1, S#state.running) of
{value, _} -> {reply, {error, {running, AppName}}, S};
false ->
case get_loaded(AppName) of
{true, _} ->
S[1] = unload(AppName, S),
cntrl(AppName, S,
{ac_application_unloaded, AppName}),
{reply, ok, S[1]};
a compiler could easily produce a warning stating that we're passing
an old instance of S, since this is almost always a bug, and can
easily be avoided in the cases when it it's intentional.
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
More information about the erlang-questions
mailing list