The problem is to prevent overriding from outside of a object.
my idea is to use setters:
var spot = function(val){
this.id = val;
this.__defineSetter__("id", function(val){alert("bang");});
}
The id should be set once in the constuctor and never be changed.
I would also like to define the setter on the prototype because I have 10.000 spots. But in this case the setter prevets access also to the consructor.
I am not willing to use var id in the constructor and define a getter on it. In this case every single one of the (10.000) objects has its own closure.
A second question is: Can the setter somehow know wether the var is changed from the constructor or later from a (spot)internal function? So I could prevent access just from outside the object.
Firstly, that code is non-standard and deprecated. Depending on the platform you're developing for, I suggest using preventExtensions or freeze. Or maybe you just want to define the id property as read-only, in which case use defineProperty.
Secondly, as you've done things, each instance of spot already has it's own closure. That setter that you defined is a unique function + lexical scope that will exist for every spot, aka closure. So I'm not sure what the big deal is with making a getter as well. Although the first point trumps here, and you should be using the new methods to achieve that functionality.
Lastly, no matter what direction you take, the setter will not be able to "know" anything. So you can either have a separate variable, something to the tune of isInitialised, or create a code invariant so that the value is undefined at first, and numeric afterwards, which allows the simple check if the variable has a defined value, in which case it's been set, and shouldn't set it again.
Related
First of all, I want to clarify, I know that with is deprecated, and using it is generally a bad practice.
However, my question is about a special case: using a special Proxy object as the parameter of with.
Background
I'm working on a project, where I have to limit access of a piece of code to the global scope.
One approach might be to use a loop with eval, that creates constant variables with the value of undefined for each property of the global object, but that seems even worse than using with, and cannot limit access to variables created with let and const.
The idea
The idea is to use a Proxy as the argument of with, whose...
has trap always returns true, therefore it doesn't allow any lookups or assignments to go beyond the with statement
get trap operates normally, except that it throws ReferenceErrors when trying to access a non-existing variable (i.e. property)
set trap operates normally (or maybe contains some custom logic)
target object has no [[Prototype]] (i.e. it was created with Object.create(null))
target object has an ##unscopables property, with the value of an empty object, to allow scoping of every property
So, something like this code:
const scope = Object.create(null)
Object.assign(scope, {
undefined,
console,
String,
Number,
Boolean,
Array,
Object,
/* etc. */
[Symbol.unscopables]: Object.create(null)
})
const scopeProxy = new Proxy(scope, {
get: (obj, prop) => {
if (prop in obj)
return obj[prop]
else
throw new ReferenceError(`${prop} is not defined`)
},
set: Reflect.set,
has: () => true
})
with(scopeProxy) {
//Sandboxed code
foo = Number('42')
console.log(foo) //42
try{
console.log(scopeProxy) //Inaccessible
}catch(e){
console.error(e) //ReferenceError: scopeProxy is not defined
}
}
Avoiding contras
There are several contras listed on the MDN's page about the with statement, but this usage of it gets rid of each.
1. Performance
The problem:
Looking up identifiers that aren't a member of with statement's parameter object is less performant.
Avoidance:
No lookups can go beyond the parameter object.
2. Ambiguity
The problem:
It is hard to decide, which identifier gets looked up of those with the same name.
Avoidance:
All lookups and assignments retrieve or modify the property of the parameter object.
3. Forward compatibility
The problem:
The properties of the parameter object or its prototype might change in the future.
Avoidance:
The parameter object is initially empty and has no prototype, therefore no properties can change.
Question
The above code works perfectly, and the contras listed on MDN don't seem to apply to this case.
So, my question is:
Is it still a bad practice to use the with statement, and if so, what are the downsides of using it in this specific case?
Note: I know that this approach in itself is not secure and can be bypassed. However, this question is limited only to whether it's considered bad for some reason to use the abovementioned Proxy-with combination. In this question, I'm not concerned about security (that's a related, but different question).
Sounds like the good old lexical vs dynamic scope topic. In general lexical scope is more safe but in some situations dynamic scope makes sense, because it simplifies some solutions very much. I would say your example is one of the cases, where it may be useful.
function foo(itemA) {
async.waterfall(
[
function(callback) {
console.log("I can see itemA as " + itemA); // <-- this works fine
callback(null);
},
outerFunction // <-- this method doesn't have access to itemA
],
function(err, item) {}
);
}
function outerFunction(callback) {
//item A is not defined so this barfs
console.log("I'm going to throw an exception cause... " + itemA);
}
For the sake of neatness I neither want to define all my functions inside the waterfall, nor do I want to play all sorts of elaborate games passing around some object that contains the values so that these methods have access to them, but I'm not clear on how (or if) it's possible to use bind or apply to give these externally defined methods access to itemA or if there's some other mechanism that I'm not familiar with that would make this possible.
No. Scope in Javascript is lexical (based on the position of the code). You cannot change the scope of a function that is already declared.
You can however simply pass itemA to outerFunction as an argument when you call it. That is the usual and expected way to solve a problem like this.
There are other techniques for giving things more automatic access to a set of variables like assigning a value to a higher, but shared scope or making things methods on a common object that all can share access to instance data, but it is not obvious from your description of the issue whether either of these is appropriate in this case.
but I'm not clear on how (or if) it's possible to use bind or apply to
give these externally defined methods access to itemA or if there's
some other mechanism that I'm not familiar with that would make this
possible.
.bind() and .apply() do not affect scope in any way. They give you control over the value of this and/or arguments to the function. If the variable of interest was available on some object, then you could use .bind(), .apply() or .call() to set the value of this to that object and allow your function to access the data via this.property.
Javascript copies objects by reference, rather than literally. For example:
var myObject = {};
var myCopy = myObject;
myObject.foo = "bar";
alert(myCopy.foo); //alerts "bar"
But I am really struggling to think of practical, real world reason for this other than giving developers a way to make code slightly more readable (as you can give different uses for the same object different names).
The most likely thing is I have missed the point, so can anyone tell me what that point is?
After writing:
var myObject = {};
There is an object out in memory somewhere that you can refer to by the name myObject. The following assignment:
var myCopy = myObject;
...says that myCopy now refers to that same object, wherever it may be. This is the same thing that happens when you give an argument to a function:
function somefunc(localName) {
// body
}
someFunc(myCopy);
Now there is a variable called localName that is local to someFunc that also refers to that same object out in memory.
This is the fundamental way in which we pass around references to an object, so that it can be referred to by different names, in different scopes.
We could copy the entire structure into a new location in memory. There was nothing stopping the designers from creating a language that did that. But it's less efficient -- think of deeply nested objects -- and generally not what you want to do. For example, if a function modified one property of an object, it would need to return the entire object for that change to persist outside of the function. And the caller would need to handle that return value, deciding whether the old object needs to be kept or if the newly created, slightly different copy can overwrite it.
Again, there's nothing wrong with this design direction in principle; it's just not how JavaScript was designed.
It depends; in your case it might be rather confusing since it doesn't serve a real purpose. However, for longer paths to the object it can be advantageous to store the object in a separate variable, because it requires less typing for each statement that uses the object, such as in this example:
var style = document.getElementById("foo").style;
style.color = "red";
style.font = "sans-serif";
// ...
My opinion (and it's nothing more than that) is that creating an object by reference (rather than copy) is generally more useful and what the user wants. If you pass an object as a param to a method, you're (almost always) interested in the object being worked on and altered by that method, rather than by working on a copy (and leaving the original untouched). Obviously there are circumstances where this is not true and it would be nice to have the option to choose, but I've can't recall ever finding myself wishing that I could just pass an object copy to a method, and am usually very grateful that the thing I'm working with is THE thing.
another question concerning javascricpt closures. I have a global "settings object". Is it better to use it from within functions in global scope or pass the object every time a function needs to access the object?
For a better understanding a little mockup of the situation here
Please ignore that "baz()" also gets the passed object within "foobar()" from the global scope within the closure. You see that both versions work fine.
The thing is that I am passing whatever object the function needs to work to every function and EVERY time (unneccesary overhead?), which might be nice and easy to read/understand but I am seriously thinking about changing this. Disadvantage would be that I have to keep the "this" scope wherever it gets deeper right?
Thanks for your advice!
Your settings object isn't global, it's defined within a closure.
As the intent is that it be accessed by other function within the closure, I'd say you were 100% fine to just access that object directly and not pass it as a parameter.
FWIW, even if you did pass it as a parameter the overhead is negligible because only a reference to the object is passed, not a copy of the whole object.
So you have basically three options:
You want to expose settings as a global variable, and have it accessed by your functions,
You want to hide settings as an implementation detail and have it accessed by your functions,
You want to give a possibility to supply different settings objects to different functions.
Global variable approach
Well, I guess it's a little bit like with any global variable. If settings is a singleton (for example it describes your application) and you can't see any benefit in having a possibility to call the same function with different settings objects, then I don't see why it couldn't be a global variable.
That said, because of all the naming conflicts, in Javascript it's good to "namespace" all the global variables. So instead of global variables foo and bar you should rather have one global variable MyGlobalNamespace which is an objects having attributes: MyGlobalNamespace.foo and MyGlobalNamespace.bar.
Private variable approach
Having a private variable accessed by a closure is a good pattern for hiding implementation details. If the settings object is something you don't want to expose as an API, this is probably the right choice.
Additional function parameter approach
Basically if you see a gain in having a possibility of supplying different settings to different function calls. Or perhaps if you can picture such gain in the future. Obvious choice if you have many instances of settings in your application.
EDIT
As to the question from the comments:
Example 1)
var blah = 123;
function fizbuzz() {
console.log(blah); // <-- This is an example of a closure accessing
// a variable
console.log(this.blah); // <-- Most likely makes no sense. It might work,
// because by default this will be set to a global
// object named window, but this is probably not
// what you want. In other situations this might
// point to another object.
}
Example 2)
var obj = {
blah: 123,
fizbuzz: function() {
console.log(this.blah); // <-- This is *NOT* an example of a closure
// accessing a private variable. It's rather the
// closest Javascript can get to accessing an
// instance variable by a method, though this
// terminology shouldn't be used.
console.log(blah); // <-- This MAKES NO SENSE, there is no variable blah
// accessible from here.
}
};
In a nutshell, I'd encourage you to read some good book on the fundamental concepts of Javascript. It has its paculiarities and it's good to know them.
Are there any benefits to using the 'window' prefix when calling javascript variables or methods in the window object? For example, would calling 'window.alert' have an advantage over simply calling 'alert'?
I can imagine using the prefix could give a small performance boost when the call is made from inside some function/object, however I rarely see this in people's code. Henceforth this question.
This is useful when attempting to test global object values. For example, if GlobalObject is not defined then this throws an error:
if(GlobalObject) { // <- error on this line if not defined
var obj = new GlobalObject();
}
but this does not throw an error:
if(window.GlobalObject) { // Yay! No error!
var obj = new GlobalObject();
}
Similarly with:
if(globalValue == 'something') // <- error on this line if not defined
if(window.globalValue == 'something') // Hurrah!
and:
if(globalObj instanceof SomeObject) // <- error on this line if not defined
if(window.globalObj instanceof SomeObject) // Yippee! window.prop FTW!
I would not expect to see a significant performance difference, and the only other reason you might do this is to ensure that you are actually getting a value from the global scope (in case the value has been redefined in the current scope).
I doubt there is any measurable performance benefit. After all the scope chain would be scanned for the identifier window first then the window object would be scanned for the desired item. Hence more likely it would be deterimental to performance.
Using window prefix is useful if you have another variable in scope that would hide the item you may want to retrieve from the window. The question is can you always know when this might be? The answer is no. So should you always prefix with window? What would you code look like if you did that. Ugly. Hence don't do it unless you know you need to.
Retrieved from Google (http://www.techotopia.com/index.php/JavaScript_Window_Object):
The window object is the top-level object of the object hierarchy. As such, whenever an object method or property is referenced in a script without the object name and dot prefix it is assumed by JavaScript to be a member of the window object. This means, for example, that when calling the window alert() method to display an alert dialog the window. prefix is not mandatory. Therefore the following method calls achieve the same thing:
window.alert()
alert()
However, I read but have not had time to test the following from:
(http://www.javascriptref.com/reference/object.cfm?key=20)
One place you'll need to be careful, though, is in event handlers. Because event handlers are bound to the Document, a Document property with the same name as a Window property (for example, open) will mask out the Window property. For this reason, you should always use the full "window." syntax when addressing Window properties in event handlers.
As far as performance, I think AnthonyWJones has it covered.
One use of the window prefix is to explicitly make something available outside the current scope. If you were writing code in a self-invoking function to avoid polluting the global scope, but there was something within that you did want to make globally available, you might do something like the following:
(function(){
function foo(){
//not globally available
}
function bar(){
//not globally available
}
window.baz = function(){
//is globally available
foo();
bar();
};
})();
I imagine that the performance benefit here is amazingly insignificant at best, if there is one at all.
It only matters if you're using frames and doing a bunch of javascript calls across frames, and even then only specific scenarios warrant the necessity of referencing window explicitly.
When you use the prefix, you're making it explicit you're using the "global" definition of the variable, not a local one. (I'm not sure whether / how you can inject variables into a scope in JS, except the weirdness with this and inline event handlers.) YMMV, you may either prefer the clarity, or find it to be just clutter.