Is closure is the way to avoid global variable?
up vote
0
down vote
favorite
I know that using global variable is not good practice and programmers should avoid it when possible.
func foo(a *A) func() *A
return func() *A
return a
If I call foo_closure
inside another function bar
it would mean that output of bar
will not depend on its input arguments and bar
cannot be pure function.
Now I cannot see a difference between accessing a *A
variable by closure or by global variable. In both cases they make an output unpredictable.
Can closure be considered an evil thing as global variable?
P.S
Other functions can also call foo_closure
and mutate its fields.
function functional-programming closures global-variables
add a comment |
up vote
0
down vote
favorite
I know that using global variable is not good practice and programmers should avoid it when possible.
func foo(a *A) func() *A
return func() *A
return a
If I call foo_closure
inside another function bar
it would mean that output of bar
will not depend on its input arguments and bar
cannot be pure function.
Now I cannot see a difference between accessing a *A
variable by closure or by global variable. In both cases they make an output unpredictable.
Can closure be considered an evil thing as global variable?
P.S
Other functions can also call foo_closure
and mutate its fields.
function functional-programming closures global-variables
1
As long as you are not mutating your environment (which is necessary for pure functions), using variables from any scope is fine - be it the global or a closure scope. Make them constants with immutable values.
– Bergi
Nov 9 at 8:21
What isfoo_closure
, what isbar
, and why do you think it can't be pure?
– Bergi
Nov 9 at 8:23
@Bergi making them global unnecessarily, though, litters the global namespace. and having them inside a closure makes the mutation safe(r)(ish) // more under control.
– Will Ness
Nov 9 at 10:33
@WillNess Sure, the variable should be placed in a local scope/namespace/whatever to avoid collisions, but my point was that the scope doesn't matter: it's only important that the variable is not mutated.
– Bergi
Nov 9 at 11:12
right; without mutation everything is pure; if we must have mutation we better have it under control.
– Will Ness
Nov 9 at 11:13
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I know that using global variable is not good practice and programmers should avoid it when possible.
func foo(a *A) func() *A
return func() *A
return a
If I call foo_closure
inside another function bar
it would mean that output of bar
will not depend on its input arguments and bar
cannot be pure function.
Now I cannot see a difference between accessing a *A
variable by closure or by global variable. In both cases they make an output unpredictable.
Can closure be considered an evil thing as global variable?
P.S
Other functions can also call foo_closure
and mutate its fields.
function functional-programming closures global-variables
I know that using global variable is not good practice and programmers should avoid it when possible.
func foo(a *A) func() *A
return func() *A
return a
If I call foo_closure
inside another function bar
it would mean that output of bar
will not depend on its input arguments and bar
cannot be pure function.
Now I cannot see a difference between accessing a *A
variable by closure or by global variable. In both cases they make an output unpredictable.
Can closure be considered an evil thing as global variable?
P.S
Other functions can also call foo_closure
and mutate its fields.
function functional-programming closures global-variables
function functional-programming closures global-variables
edited Nov 9 at 11:48
asked Nov 9 at 6:43
Roma Karageorgievich
1,52431445
1,52431445
1
As long as you are not mutating your environment (which is necessary for pure functions), using variables from any scope is fine - be it the global or a closure scope. Make them constants with immutable values.
– Bergi
Nov 9 at 8:21
What isfoo_closure
, what isbar
, and why do you think it can't be pure?
– Bergi
Nov 9 at 8:23
@Bergi making them global unnecessarily, though, litters the global namespace. and having them inside a closure makes the mutation safe(r)(ish) // more under control.
– Will Ness
Nov 9 at 10:33
@WillNess Sure, the variable should be placed in a local scope/namespace/whatever to avoid collisions, but my point was that the scope doesn't matter: it's only important that the variable is not mutated.
– Bergi
Nov 9 at 11:12
right; without mutation everything is pure; if we must have mutation we better have it under control.
– Will Ness
Nov 9 at 11:13
add a comment |
1
As long as you are not mutating your environment (which is necessary for pure functions), using variables from any scope is fine - be it the global or a closure scope. Make them constants with immutable values.
– Bergi
Nov 9 at 8:21
What isfoo_closure
, what isbar
, and why do you think it can't be pure?
– Bergi
Nov 9 at 8:23
@Bergi making them global unnecessarily, though, litters the global namespace. and having them inside a closure makes the mutation safe(r)(ish) // more under control.
– Will Ness
Nov 9 at 10:33
@WillNess Sure, the variable should be placed in a local scope/namespace/whatever to avoid collisions, but my point was that the scope doesn't matter: it's only important that the variable is not mutated.
– Bergi
Nov 9 at 11:12
right; without mutation everything is pure; if we must have mutation we better have it under control.
– Will Ness
Nov 9 at 11:13
1
1
As long as you are not mutating your environment (which is necessary for pure functions), using variables from any scope is fine - be it the global or a closure scope. Make them constants with immutable values.
– Bergi
Nov 9 at 8:21
As long as you are not mutating your environment (which is necessary for pure functions), using variables from any scope is fine - be it the global or a closure scope. Make them constants with immutable values.
– Bergi
Nov 9 at 8:21
What is
foo_closure
, what is bar
, and why do you think it can't be pure?– Bergi
Nov 9 at 8:23
What is
foo_closure
, what is bar
, and why do you think it can't be pure?– Bergi
Nov 9 at 8:23
@Bergi making them global unnecessarily, though, litters the global namespace. and having them inside a closure makes the mutation safe(r)(ish) // more under control.
– Will Ness
Nov 9 at 10:33
@Bergi making them global unnecessarily, though, litters the global namespace. and having them inside a closure makes the mutation safe(r)(ish) // more under control.
– Will Ness
Nov 9 at 10:33
@WillNess Sure, the variable should be placed in a local scope/namespace/whatever to avoid collisions, but my point was that the scope doesn't matter: it's only important that the variable is not mutated.
– Bergi
Nov 9 at 11:12
@WillNess Sure, the variable should be placed in a local scope/namespace/whatever to avoid collisions, but my point was that the scope doesn't matter: it's only important that the variable is not mutated.
– Bergi
Nov 9 at 11:12
right; without mutation everything is pure; if we must have mutation we better have it under control.
– Will Ness
Nov 9 at 11:13
right; without mutation everything is pure; if we must have mutation we better have it under control.
– Will Ness
Nov 9 at 11:13
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
The output is unpredictable with a global variable if "something else" besides your function yourfunc
changes the global variable's value in between the calls to yourfunc
.
But if the variable var
is enclosed inside a closure and is accessible only to yourfunc
, nothing else has access to it so can't change it so yourfunc
's output becomes entirely predictable by the arguments to yourfunc
and by yourfunc
's actions (like, mutating the enclosed variable var
, which can only be done from inside yourfunc
).
Which increases safety and purity, which is the whole point to having closures in the first place.
The value of a function depends on its environment, comprised of its arguments, and the enclosed variables.
Another use of closures is when the enclosed environment is shared between several functions, so that only those functions can access and alter the enclosed variables' values.
Having variables global unnecessarily, litters the global name space and makes them liable for erroneous access.
Ifyourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.
– Bergi
Nov 9 at 11:10
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
wherevermy_function
is called from, only the code insidemy_function
has access to the enclosed variable.
– Will Ness
Nov 9 at 11:17
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The output is unpredictable with a global variable if "something else" besides your function yourfunc
changes the global variable's value in between the calls to yourfunc
.
But if the variable var
is enclosed inside a closure and is accessible only to yourfunc
, nothing else has access to it so can't change it so yourfunc
's output becomes entirely predictable by the arguments to yourfunc
and by yourfunc
's actions (like, mutating the enclosed variable var
, which can only be done from inside yourfunc
).
Which increases safety and purity, which is the whole point to having closures in the first place.
The value of a function depends on its environment, comprised of its arguments, and the enclosed variables.
Another use of closures is when the enclosed environment is shared between several functions, so that only those functions can access and alter the enclosed variables' values.
Having variables global unnecessarily, litters the global name space and makes them liable for erroneous access.
Ifyourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.
– Bergi
Nov 9 at 11:10
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
wherevermy_function
is called from, only the code insidemy_function
has access to the enclosed variable.
– Will Ness
Nov 9 at 11:17
add a comment |
up vote
1
down vote
The output is unpredictable with a global variable if "something else" besides your function yourfunc
changes the global variable's value in between the calls to yourfunc
.
But if the variable var
is enclosed inside a closure and is accessible only to yourfunc
, nothing else has access to it so can't change it so yourfunc
's output becomes entirely predictable by the arguments to yourfunc
and by yourfunc
's actions (like, mutating the enclosed variable var
, which can only be done from inside yourfunc
).
Which increases safety and purity, which is the whole point to having closures in the first place.
The value of a function depends on its environment, comprised of its arguments, and the enclosed variables.
Another use of closures is when the enclosed environment is shared between several functions, so that only those functions can access and alter the enclosed variables' values.
Having variables global unnecessarily, litters the global name space and makes them liable for erroneous access.
Ifyourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.
– Bergi
Nov 9 at 11:10
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
wherevermy_function
is called from, only the code insidemy_function
has access to the enclosed variable.
– Will Ness
Nov 9 at 11:17
add a comment |
up vote
1
down vote
up vote
1
down vote
The output is unpredictable with a global variable if "something else" besides your function yourfunc
changes the global variable's value in between the calls to yourfunc
.
But if the variable var
is enclosed inside a closure and is accessible only to yourfunc
, nothing else has access to it so can't change it so yourfunc
's output becomes entirely predictable by the arguments to yourfunc
and by yourfunc
's actions (like, mutating the enclosed variable var
, which can only be done from inside yourfunc
).
Which increases safety and purity, which is the whole point to having closures in the first place.
The value of a function depends on its environment, comprised of its arguments, and the enclosed variables.
Another use of closures is when the enclosed environment is shared between several functions, so that only those functions can access and alter the enclosed variables' values.
Having variables global unnecessarily, litters the global name space and makes them liable for erroneous access.
The output is unpredictable with a global variable if "something else" besides your function yourfunc
changes the global variable's value in between the calls to yourfunc
.
But if the variable var
is enclosed inside a closure and is accessible only to yourfunc
, nothing else has access to it so can't change it so yourfunc
's output becomes entirely predictable by the arguments to yourfunc
and by yourfunc
's actions (like, mutating the enclosed variable var
, which can only be done from inside yourfunc
).
Which increases safety and purity, which is the whole point to having closures in the first place.
The value of a function depends on its environment, comprised of its arguments, and the enclosed variables.
Another use of closures is when the enclosed environment is shared between several functions, so that only those functions can access and alter the enclosed variables' values.
Having variables global unnecessarily, litters the global name space and makes them liable for erroneous access.
answered Nov 9 at 10:40
Will Ness
42.3k467118
42.3k467118
Ifyourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.
– Bergi
Nov 9 at 11:10
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
wherevermy_function
is called from, only the code insidemy_function
has access to the enclosed variable.
– Will Ness
Nov 9 at 11:17
add a comment |
Ifyourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.
– Bergi
Nov 9 at 11:10
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
wherevermy_function
is called from, only the code insidemy_function
has access to the enclosed variable.
– Will Ness
Nov 9 at 11:17
If
yourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.– Bergi
Nov 9 at 11:10
If
yourfunc
mutates the variable it closes over, it becomes stateful and is no longer pure.– Bergi
Nov 9 at 11:10
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
yes, and this impurity is under its exclusive control. Haskell has State too.
– Will Ness
Nov 9 at 11:11
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
You might have restricted where the mutation can occur in your code (so that it's easier to reason about, especially in the absence of multithreading), but it's not "under control" as you don't restrict where the closure can be called in the application.
– Bergi
Nov 9 at 11:15
wherever
my_function
is called from, only the code inside my_function
has access to the enclosed variable.– Will Ness
Nov 9 at 11:17
wherever
my_function
is called from, only the code inside my_function
has access to the enclosed variable.– Will Ness
Nov 9 at 11:17
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53220997%2fis-closure-is-the-way-to-avoid-global-variable%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
As long as you are not mutating your environment (which is necessary for pure functions), using variables from any scope is fine - be it the global or a closure scope. Make them constants with immutable values.
– Bergi
Nov 9 at 8:21
What is
foo_closure
, what isbar
, and why do you think it can't be pure?– Bergi
Nov 9 at 8:23
@Bergi making them global unnecessarily, though, litters the global namespace. and having them inside a closure makes the mutation safe(r)(ish) // more under control.
– Will Ness
Nov 9 at 10:33
@WillNess Sure, the variable should be placed in a local scope/namespace/whatever to avoid collisions, but my point was that the scope doesn't matter: it's only important that the variable is not mutated.
– Bergi
Nov 9 at 11:12
right; without mutation everything is pure; if we must have mutation we better have it under control.
– Will Ness
Nov 9 at 11:13