foo = 'var'
basically coffeescript generates
(function(){var foo = 'bar';}).call(this);
But in the console I can't access the variable foo
console.log(foo);// error ReferenceError: Can't find variable: foo
How can I access the variable, and what's the point coffeescript do something like this?
This ensures that variables declared within that file don't accidentally leak into the global namespace. It forces the programmer to be more explicit about the variables that he chooses to expose.
If you'd like to expose foo do (exports ? this).foo = 'bar'.
Take a look at this question and answers for reference: How do I define global variables in CoffeeScript?
Related
I'm new to Lua "classes" (metatables) and I have a doubt.
In the following constructor code that I wrote, I declared the variable obj as local. But in most examples on the web, this variable is just assigned to without a local declaration. So in my understanding, it becomes a global variable (not efficient from what I understood). But is there a reason for that?
A = {}
A.__index = A
function A:new(obj_init)
local obj = obj_init or {val = 0}
setmetatable(obj, A)
return obj
end
I also noticed that members of the class can be accessed directly, even from another Lua module:
x = A:new{val = 2}
print(x.val)
But is there a way to make val a private member? Maybe also using local?
First, let's look at what these examples you found might have looked like.
Parameters: Implicit locals
function A:new(obj)
obj = obj or {val = 0}
...
end
in this snippet, obj is a local variable. This is because all function parameters in Lua are local variables. We may rewrite the function as follows to highlight this:
function A:new(...)
local obj = ...
obj = obj or {val = 0}
end
I assume this is what you saw e.g. in the PIL. You probably renamed the parameter to obj_init, losing the implicit local declaration of obj.
Global assignment
If you happened to consume particularly bad resources, you might have seen the following:
function A:new(obj_init)
obj = obj_init or {val = 0}
...
end
in this snippet, obj is indeed a global variable. This is very bad for multiple reasons:
Efficiency: You are right - excepting pathological cases, global variables are always slower than local variables as global variables are entries in the (hash part of the) _G table whereas locals are stored in fast registers of the Lua VM.
Code quality: Global pollution: This constructor now has a side effect: It modifies the global variable obj and expects it to not be modified during its execution. This might lead to this function overwriting a global variable obj and, even worse, you may not yield from a coroutine in the constructor now, because you're dependent on a global state which may not be altered.
Private members
The typical way to implement private table fields in Lua is by convention: You may prefix the field names with an underscore to indicate that these fields may not be modified from outside. Of course programmers are free to circumvent this.
Otherwise, the concept of "private" variables doesn't mesh too well with the scripting language nature of Lua; you can shoehorn full-fledged OOP onto Lua using metatables, but it will be neither idiomatic nor efficient.
Upvalues
The most idiomatic way to implement private members in Lua is to have them be upvalues of closures ("accessors"):
A = {}
A.__index = A
function A:new(obj_init)
local obj = {} -- empty object: only member is private
local val = obj.val
-- note: this does not need `self`, thus no `:` is used;
-- for setters you might want to discard `self` for consistency
function obj.getVal()
return val
end
setmetatable(obj, A)
return obj
end
x = A:new{val = 2}
print(x.getVal())
-- val can not be set from outside (excepting the debug library);
-- it is "private" and only accessible through the getter method
The downside is that all functions accessing your private members will have to be instantiated with each object creation.
Note that even upvalues aren't fully "private" as they may be accessed through the debug library.
debug library workarounds
The debug library allows you to inspect the stack. This allows you to tell which method triggered your __index metamethod. You could thus return different values to different callers. This may be nice for a proof-of-concept to showcase Lua's metaprogramming capabilities, but should not be done in practice as it is very inefficient and hacky.
I must admit that I didn't expect the following code could work (code sample from a collegue of mine):
def foo():
li.append(3)
li = [1, 2]
foo()
print(li) # gives [1, 2, 3]
My questions are:
why is 'global li' not needed in the 'def foo()'?
why is 'li = [1, 2]' not needed to be put before the 'def foo()'?
ps. Python 3.6.1 is used for the listed code sample.
Global keyword is a keyword that allows a user to modify a variable outside of the current scope.
Rules of global keyword:
If a variable is assigned a value anywhere within the function’s
body, it’s assumed to be a local unless explicitly declared as
global.
Variables that are only referenced inside a function are
implicitly global.
We Use global keyword to use a global variable inside a
function.
There is no need to use global keyword outside a function.
Your code , you are not changing or assigning a 'li' value
2.Here list is defined before foo() is called, so it working fine.suppose if you call foo() before li is defined, it will throw a error like NameError: name 'li' is not defined
Since the list is defined before foo() is called, hence there is no error.
global keyword is only required when we want to do assignment or change the global variable. Accessing the methods or printing the variable does not require the global keyword
I've tried searching for an explanation on this exact scenario but couldn't find anything. I have a module that looks like the following (simplified):
export default function(name) {
return map[name];
}
const map = {
'a': 'b',
'b': 'c'
};
Clearly the const definition above is hoisted but it should be undefined when being used in the function. I'm trying to find an exact explanation for why this function works when imported and used. Shouldn't a reference error be thrown? The only thing I can think of is that the entire module is loaded prior to when this function is called, but how exactly does that happen or where is this specific behavior explained? Any information would be really appreciated.
JS uses lexical scoping, meaning that a scope is defined as part of the nested structure of the code. Anything referencing the name of a variable anywhere in that scope can attempt to access the value. What the actual value is depends on when the value is initialized, which is a runtime property of the code.
When people talk about hoisting in JS generally it is not super clear which of these things they are describing. In JS, because scopes are lexically-based, the existence of a given variable is hoisted, in that it always exists within that scope.
The actual initialization of a variable in a scope depends on the way the variable is declared.
function foo(){} declarations have their initialization hoisted, so the variable foo will always be available in the body of the function, even if the declaration comes later. e.g.
foo();
function foo(){}
is perfectly valid valid.
var foo = 4; hoists initialization, but the value is initialized to undefined until the declaration has executed, e.g.
foo; // undefined
var foo = 4;
foo; // 4
let/const performs initialization only when executed, and attempts to access uninitialized variables will throw an exception.
foo; // would throw because it is not initialized yet
let foo = 4;
foo; // 4
So taking those together, the behavior of variables is only determined at runtime. For your code example, it depends on when the function is called. Since let foo = 4; only initialized foo when it runs, if the function were called first, it would fail, and if the function were called after, it would work.
function log(){
console.log(foo);
}
log(); // would throw because foo has not been initialized
let foo = 4;
log(); // would log 4
This behavior of delayed initialization for let and const is commonly referred to as the "temporal dead zone".
At the end of the day, as long as the variable has been initialized and has the value you care about by the time you access it, your code is fine. Whether you have access to the variable in the first place only depends on the nesting of your code.
The call can only be made (outside of this module) after the whole module you provided is executed (which means that map is already initialized by the time the function is called)
This observation is based on the fact that when you import a module, all of the code inside it will be executed.
To call the function, one would have to import the module you provided.
See Does ES6 module importing execute the code inside the imported file? for when code executes on import.
What is the difference between global variable and shared instance in Swift? what are their respective field of use? Could anyone clarify their concept based upon Swift.
A global variable is a variable that is declared at the top level in a file. So if we had a class called Bar, you could store a reference to an instance of Bar in a global variable like this:
var bar = Bar()
You would then be able to access the instance from anywhere, like this:
bar
bar.foo()
A shared instance, or singleton, looks like this:
class Bar {
static var shared = Bar()
private init() {}
func foo() {}
}
Then you can access the shared instance, still from anywhere in the module, like this:
Bar.shared
Bar.shared.foo()
However, one of the most important differences between the two (apart from the fact that global variables are just generally discouraged) is that the singleton pattern restricts you from creating other instances of Bar. In the first example, you could just create more global variables:
var bar2 = Bar()
var bar3 = Bar()
However, using a singleton (shared instance), the initialiser is private, so trying to do this...
var baaar = Bar()
...results in this:
'Bar' initializer is inaccessible due to 'private' protection level
That's a good thing, because the point of a singleton is that there is a single shared instance. Now the only way you can access an instance of Bar is through Bar.shared. It's important to remember to add the private init() in the class, and not add any other initialisers, though, or that won't any longer be enforced.
If you want more information about this, there's a great article by KrakenDev here.
Singleton (sharing instance)
Ensure that only one instance of a singleton object is created & It's provide a globally accessible through shared instance of an object that could be shared even across an app.
The dispatch_once function, which executes a block once and only once for the lifetime of an app.
Global variable
Apple documentation says Global variables are variables that are defined outside of any function, method, closure, or type context.
I have a need to access common properties within my class functions and, unfortunately, outside my class in other functions.
For example
Class Myclass {
[Void]my_function(){
$file_location = "$myvar"
}
}
properties { # some props
$myvar = "somefile.txt"
}
function do_things{
echo $myvar
}
When I attempt to access $myvar within my_function as part of the class, I get a parsing error "variable is not defined in the method" which makes sense as the variable isn't declared in the class, but I would imagine things in a properties block would be usable.
I'm hoping there is something I"m not aware of and haven't been able to find in the documentation that allows me to do this. It seems rather silly that I can't use properties within my class functions.
My current (unfavorable) solution is to have my class inherit from another class that just has a bunch of static variables defined in it since you can access those anywhere else in the script by doing [MyOtherClass]::static_variable_name. This just isn't how I'd prefer to do it.
Please advise
I can not provide reference right now, but I remember reading in some PowerShell blog, that purpose of this feature is to make PowerShell classes to be more self containing and to catch error early, for example, if you misspell variable name.
Parser simply disallow you to reference random variables in class method body directly, unless you prefix it with global or script scope. But, apparently, no technical restriction was made to prevent you from referencing variables in any other way.
So that, you can ask Get-Variable to read variable value for you:
Get-Variable myvar -ValueOnly
And you even can make this, because nested script blocks are not analyzed:
&{$myvar}