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.










share|improve this question



















  • 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 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










  • @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














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.










share|improve this question



















  • 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 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










  • @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












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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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










  • @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




    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











  • @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












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.






share|improve this answer




















  • 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











  • 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











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















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

























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.






share|improve this answer




















  • 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











  • 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















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.






share|improve this answer




















  • 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











  • 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













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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 9 at 10:40









Will Ness

42.3k467118




42.3k467118











  • 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











  • 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

















  • 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











  • 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
















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


















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Edmonton

Crossroads (UK TV series)