Re: [JSMentors] Null prototype and inheritance
Nick Morgan: > Now, if you do this instead: > > Ctor.prototype = null; > > var y = new Ctor; > > y.toString; > => function ... > > Here's a fiddle that illustrates the above: > http://jsfiddle.net/skilldrick/gabEN/ > > So, how is `toString` looked up on `y`? Is there a special case when the > constructor's prototype property is null, or am I misunderstanding > something? You should look at 13.2.2 [[Construct]]. 1. Let obj be a newly created native ECMAScript object. 4. Let proto be the value of calling the [[Get]] internal property of F with argument "prototype". 5. If Type(proto) is Object, set the [[Prototype]] internal property of obj to proto. 6. If Type(proto) is not Object, set the [[Prototype]] internal property of obj to the standard built-in Object prototype object as described in 15.2.4. So when you do: new Ctor; According step 6 you will get object which prototype chain should look as: instance obj -> Object.prototype -> null -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Prototype.constructor does this do something ?
2011/10/25, Arian Stolwijk : > instanceof only looks at what's in the prototype chain: > http://jsfiddle.net/AZbvp/ Please post the code directly in your message next time. I don't know how jsfiddle manages its shared codes, but if it expires it will be lost for JSMentors archive. Also if jsfiddle is temporarily unavailable the JSMentors subscribers would not able to get your example. You could post code in message and post a link to jsfiddle. Thank you. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Invitation to connect on LinkedIn
Could you stop "discuss" in this thread? Thank you. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] How to restore Object.prototype.hasOwnProperty if it has been overwritten?
Lasse Reichstein:
> You can use either Object.getPrototypeOf or __proto__ (with a preference on
> the other, because it's not as easily modified) to check:
>prop in object && !(prop in object.__proto__)
> which is not same check as hasOwnProperty (if the property is both on the
> object and also in its prototype chain), but might work in cinch.
In general interesting solution. Unfortunately it should be mention
that it won't work in case of shadowing property from the prototype
chain.
var obj = Object.create({foo: "Inherit"});
obj.foo = "Own";
"foo" in obj && !("foo" in obj.__proto__) //false
If there is mutable `__proto__' he is able to truncate the prototype
chain, check with `in` and then restore the state of the prototype
chain.
function hasOwnProp(o, p) {
var proto = o.__proto__,
res;
o.__proto__ = null;
res = p in o;
o.__proto__ = proto;
return res;
}
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Fun interview question with function expressions
gaz Heyes :
> I found this which was quite surprising:
>
> !function x(){x=123;alert(x);}()
>
> What's the value of x without running the code?
Should be `function x(){x=123;alert(x);}`, while NFE adds in front of
the scope chain `x` which value can't be overwritten so in the body of
function:
x=123;
will silently fail and `alert(x)' should alerting `function
x(){x=123;alert(x);}`.
Am I correct?
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] "Essentials of interpretation" Lesson 5. Simple user-defined functions.
gaz Heyes : > Well you better stop doing that since it's a syntax error The other members pointed out what I meant. Yes, the first RegExp include "I" as a modifier. I posted first message trough my phone. Obviously I've leaved "Caps Lock" :( Sorry for the confusion: /^[A-Z_$][A-Z0-9_$]*$/I Should be: /^[A-Z_$][A-Z0-9_$]*$/i Regards, Asen -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] "Essentials of interpretation" Lesson 5. Simple user-defined functions.
gaz Heyes : > You could shorten that to: > /^[a-z_$][\w$]*$/i > > Much cleaner :P You are correct it's shorter, but personally I prefer previous variant of that RegExp. I think it's more verbose than `\w`. Also when I use `i` modifier I always use upper case letters in RegExp literal because they are easier for reading. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] "Essentials of interpretation" Lesson 5. Simple user-defined functions.
Instead of Unicode support, ASCII letters in educational article are completely enough. You can split identifiers in two parts. First letter and everything else. So the RegExp would be: /^[A-Z_$][A-Z0-9_$]*$/I While this is for checking purposes you don't have to care abou the case of letters. Also I think the RegExp fits into you article and it's enough compact. On Aug 31, 2011 6:08 PM, "Dmitry A. Soshnikov" wrote: > The next part of implementing an interpreter is out. > > "Essentials of interpretation" Lesson 5. Simple user-defined functions. > > https://github.com/DmitrySoshnikov/Essentials-of-interpretation/blob/master/src/lesson-5.js > > Dmitry. > > -- > To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ > > To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ > > To unsubscribe from this group, send email to > jsmentors+unsubscr...@googlegroups.com -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] ES5 shims
Stoyan Stefanov:
> What ES5 shims are you using that you can recommend?
As you know some of the general ES5 features cannot be implemented in
ES3 environment. Those which rely on internal properties and their
values in most cases cannot be emulated. For example `defineProperty',
`getOwnPropertyNames', `seal', `freeze' etc.
In other hand, some can be implemented but not exactly how
specification defines. For example `Function.prototype.bind' rely on
internal properties. Even that you are able to implement version of
`bind' which is close to the spec. Look at their `bind' https://github.com/kriskowal/es5-shim >
According to spec. function created by `bind' does not have
`prototype' property. If you ignore this you are able to implement
`bind' in simpler way:
Function.prototype.bind = function (thisVal) {
var target = this,
args = [].slice.call(arguments, 1);
function f () {
var that = this instanceof f ? this : thisVal;
return target.apply(that, ([].push.apply(args, arguments), args));
};
f.prototype = this.prototype;
return f;
};
I think it's better when implement fallback version of certain ES5
feature to keep the essential behavior instead of implemented step by
step, how the specification defines.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Zakas Blog == Censored
"Via the JSMentors mailing list you can: Discuss ECMA-262 standard Discuss different implementations of ECMA-262 Discuss different host environments of JavaScript Discuss implementation of algorithms in JavaScript Discuss your library design Review your code Review your book on JavaScript topic Review your article on JavaScript topic Via the JSMentors mailing list you must not: Insulting other subscribers Post racism Spam publications" According the rules of JSMentors, your post is irrelevant and it's contradiction of rules. Nicholas Zakas is free to post or NOT comments in *his* blog. This topic is not related with JSMentors. Regards, Asen 2011/5/21, dhtml : > Hey all, > > Just wanted to throw out a friendly bit of advice to the newbies. > > Blog author and JSMentor "Nicholas Zakas" censors his blog comments > and doesn't take any feedback or criticism. > > I sometimes try and correct wrong advice when I see it. But it sure is > frustrating when the author hides/disproves comments that I took time > to write out. > > I can understand promoting one's career but the author's act of > censoring a purely technical comments should give a clue that maybe > there's something something wrong with what was written (or why would > he have to censor it, when he could just rebut). > > If it was an accident, then I apologize, however, I don't even bother > emailing him anymore because it never worked out in the past. This has > happened before and went through the emails/messages on Twitter but > didn't get responses that way. > > Just a notice for the community here about Zakas' blog. > > Garrett > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/jsmentors@jsmentors.com/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/jsmentors@googlegroups.com/ > > To unsubscribe from this group, send email to > jsmentors+unsubscr...@googlegroups.com > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Does a function always keep its reference to the outer scope?
Anton Kovalyov: > We were talking with colleagues about closures and this question came up. > When JavaScript interpreters parse a function, do they always keep its > reference to the outer scope or do they keep it _only_ when needed (i.e. > when something inside the function accesses variables from a closure)? Even that you have got your answer, your question depends on how a particular function has been created. For example if you use `Function` constructor it never form a closure with VO of calling execution context. In this case the [[Scope]] property of the created function always refers the Global Object. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] Donations
Hi everyone. We launched donations for JSMentors trough the PayPal: http://jsmentors.com/> The collected money will be used for the hosting, domain name, conferences and some reconstructions of the site. Any amount of donation is highly appreciated. Thank you very much! -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Object name
Shreyas Subramaniam:
> var foo = function() {
> //some class
> }
>
> foo.prototype.makeJSONPCall = function() {
> }
>
> foo.prototype.responseHandler = function(str) {
> this.value = str;
> }
>
> var a = new foo();
> var b = new foo();
> var c = new foo();
>
> So, a.responseHandler needs to be the callback fn for a.makeJSONPCall. I
> know this behavior can be achieved in other ways(by pushing instances into
> an array), but was wondering if any of you have come up with a better way to
> achieve this.
Probably I am too pedantic, but please use explicit semicolon when it
is necessary.
You do not need to get the name of certain variable here, even you
should not use array which holds the instances. Just use the `this`
value and it can be achieved easier.
foo.prototype.makeJSONPCall = function() {
var that = this,
callback = function (str) {
that.responseHandler(str);
};
};
Hope this helps.
Regards.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Bad Coercion Advice from a Guru (or why you should question everything)
J.R.:
> Instead of:
> if (window.ActiveXObject) {
>
> We should use:
> if (typeof window.ActiveXObject !== "undefined") {
I would not use both approaches. I would use:
if (typeof ActiveXObject != 'undefined') {
//...
}
Or as Diego proposed:
if ('ActiveXObject' in this) {
//...
}
When this code is evaluated in Global Execution Context everything
will be OK and the code is portable in every environment which use
JScript implementation.
`ActiveXObject' is a built-in function in JScript. It is a Microsoft
extension of JScript. For that reason I would use typeof with
`ActiveXObject' identifier which resolved from Scope Chain or directly
check the prototype chain of Global Object for property name
`ActiveXObject`.
I do not know how that test is reasonable when we need certain
instance of ActiveXObject. The problem here is in the architecture of
`ActiveXObject'. For example to access the file system, you should:
var fso = new ActiveXObject("Scripting.FileSystemObject");
You cannot be sure that will not throw an error. So the better
approach is to wrap in try-catch block.
var fso;
try {
fso = new ActiveXObject("Scripting.FileSystemObject");
}catch (e) {}
And you can skip the part where detect existence of `ActiveXObject' in
the scope chain. For example XHR:
if (window.XMLHttpRequest != undefined) {
//...
}
else {
try {
//.. try with ActiveXObject
} catch (e) {}
}
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Choosing between two ways to obviate global namespace pollution
jemptymethod :
> I inherited some code that essentially does this:
You should consider how these changes will affect on existing code in
your application. In order to prevent incompatibilities with existing
code, you should decide the best approach for you.
> user = deserializeUser(params); //var seemingly omitted by design
> initViewPort();
>
> initViewPort() in turn calls:
>
> initHeaderPanel();
> initMenuPanel();
> initQuotesPanel();
The problem here is not only `user' variable. Each of `initViewPort',
`initHeaderPanel', `initMenuPanel', `initQuotesPanel' are global. So
they are also global pollutions.
You can use the follow design:
var widget = (function () {
var user; //Assign a value of user
function initViewPort() {
//...
}
function initHeaderPanel() {
//...
}
function initMenuPanel() {
//...
}
function initQuotesPanel() {
//...
}
return {
initViewPort : initViewPort,
initHeaderPanel : initHeaderPanel,
initMenuPanel : initMenuPanel,
initQuotesPanel : initQuotesPanel
}
})();
widget.initViewPort();
widget..initHeaderPanel();
widget..initMenuPanel();
widget..initQuotesPanel();
Read also:
http://peter.michaux.ca/articles/how-i-write-javascript-widgets>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Javascript JSON parser according ECMA-262-5 JSON grammar
Diego Perini:
> I have one question, without having gone through reading the specs.
>
> Would it be useful, and still spec compliant, to detect an "Invalid
> leading comma" too as an error instead of a "Invalid property name" ?
>
> You already detect the "Invalid trailing comma" and the passed objects
> could be generated dynamically, it would just improve the explicit
> error in the eyes of the developer and pointing them to a less
> deviating reason.
It is useful and I have already done it.
http://asenbozhilov.com/json.html>
[, 10, 20] -> Invalid leading comma
{, "foo" : "bar"} -> Invalid leading comma
But:
{"foo" : "bar" ,, "baz" : "bar"} -> Invalid property name
[10,,20] -> Illegal punctoator
Does it make sense? Probably I have to change "Invalid property name"
with more meaningful message:
e.g. "Invalid token.type where expect string property name" ?
Regarding trailing comma I added it explicitly because some major
implementations allowed it in JSON string. See:
http://asenbozhilov.com/json-parse.html>
> This is just something that came up by trying to make your parser fail :)
>
> It is invaluable to have an independent JSON parser to test various
> browsers implementations and at the same time test our own stuff.
>
> Thank you !
I am glad that you find it useful!
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Javascript JSON parser according ECMA-262-5 JSON grammar
Scott Sauyet: > Not at all. Have you done any performance tests? I haven't yet. I am planning to test against built-in JSON.parse and various Crockford's implementation. I have made front-end for this code: http://asenbozhilov.com/json.html> You can use it as a validator of your JSON strings. I am glad you like it ;) -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Nested Property Access
Sam Merrell:
> What are the groups thoughts on safely accessing a nested objects
> value that may be undefined?
Firstly you should answer on the question, are you going to create
objects which properties value may be undefined?
> I recently came across a blog post [1]
> from Oliver Steele where he did a shortcut that looks like this:
>
> var person = {address: {zip: 1234}},
> person2 = {};
> console.log("Person2 undefined: " +
> ((person2||{}).address||{}).zip || "no zip");
This looks broken by design. Usually you are not going to create such
a code. You must NOT existence of properties during accessing stage.
First of all you should define the semantic of `persons`. The user of
code must follow this semantic and you would not need to check
properties, especially in this way.
Another approach is to create constructor `Person' who will be
responsible for these things. In constructor your are going to deal
with the default values and etc.
And when you access e.g `zip` property you must write:
personN.address.zip;
Now you are get the default value of `zip` or user defined.
If this object is not created by your constructor and does not follow
the semantic of `person` you will get valuable TypeError, which will
help you to consider the problem.
At all you shouldn't create magic code and should think about for easy
debugging.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Configuration Object API
Scott Sauyet:
> I'm looking for a critique of an API. I built this some months ago,
> and
> might need it again, and would love to have other eyes on it.
>
> On a recent project I found myself in need of some configuration data
> that could be easily changed, data in which one value was based upon
> another. And I created a generic constructor function to do it. I
> have no idea if this would be useful to anyone else, but just in case,
> I thought I'd share.
If I remember correct I and Stefan Weiss have discussed the API at
c.l.js before. It seems API is enough useful and convenient, I am
interested in the opinion of the others members, too.
Only one issue with:
merge = function(base, ext) {
//...
};
I don't know which engines are target of your code, but older JScript
versions has trouble with enumeration of user defined properties which
are same as bult-in properties of `Object.prototype'.
See the blog post of Garret:
http://dhtmlkitchen.com/learn/js/enumeration/dontenum.jsp>
If you are interested, see how I've fixed the issue:
https://github.com/abozhilov/Duke/blob/master/src/Duke.js>
See `mixin' and detection of DontEnum bug.
HTH
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Javascript JSON parser according ECMA-262-5 JSON grammar
Scott Sauyet: > I look forward to seeing it. Nice job so far! I implemented abstract `walk` operation and therefore I added an optional argument `reviver'. Both are according ECMA-262-5. You can see the changes: https://github.com/abozhilov/json/blob/master/src/json.js> Also I changed the first example, where I put little demo of `reviver'. https://github.com/abozhilov/json/blob/master/examples/parse-1.js> Any other suggestions or improvements are appreciated. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Javascript JSON parser according ECMA-262-5 JSON grammar
Scott Sauyet : > Have you considered allowing a reviver function? Perhaps it's not > important to your "testing and debugging purposes", but it might be an > interesting extension... The main goal was to create proper parser, but I like the idea for reviewer function and I'll add it. I made some changes for public API. I made `evalJSON' public wrapper for parser, and the reviewer function will be passed as second argument to `evalJSON'. If you have github account, watch the repository and you will see the changes. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] Javascript JSON parser according ECMA-262-5 JSON grammar
I wrote full JSON parser according ECMAScript 5 JSON grammar. https://github.com/abozhilov/json/tree/master/src > It pases all test case from: http://asenbozhilov.com/json-parse.html> I wrote this for testing and debugging purposes, not for fallback of `JSON.parse'. Criticism, additions and improvements are welcome. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Note 4. Two words about "hoisting".
DaveC: > I think it worth a further nod wrt function statements inside of a > block statement. I agree. My example was to show how can FunctionStatement can be confused with FunctionDeclaration and that lead more confusion in the reader. > ECMAScript allows syntactic extensions, one such extension is to allow > function statements inside of a block statement currently Mozilla is > the only vendor (*I think*) that has added this extension - While this is syntax extension, by my observations I think all major implementation support it, otherwise they must throw a SyntaxError. FunctionStatement syntactically is exactly as FunctionDeclaration. The main difference is that FunctionDeclration cannot appear in Statements, while FS can. You talk about it the semantic of FunctionStatement. While this is not defined by ECMA-262 standard, interpretation of FS is implementation depended. IMHO Mozilla implementation is proper at least because this FunctionStatement. > so I would > advise against it's use as the behaviour it will inconsistent across > browsers. > > See this explanation on clj http://bit.ly/eu5rqw Absolutely agree. And your test case proves your advice. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Note 4. Two words about "hoisting".
Dmitry A. Soshnikov :
> http://dmitrysoshnikov.com/notes/note-4-two-words-about-hoisting/
Excellent article.
The most interesting example for me was:
// a.js
function foo() {
alert(1);
}
foo(); // 2 ?
// b.js
function foo() {
alert(2);
}
Which demonstrates how Function Declarations are created during
variable instantiation time on entering in particular execution
context. And especially how the second declaration replace the value
of created property of variable object or lexical environment.
However, sometimes if you know how it works FD you can be confused
from non-standard Function Statements.
e.g.
foo(); //It will alert 1
function foo() {
alert(1);
}
if (true) {
function foo() {
alert(2);
}
}
foo(); //2
While the first is FD and will be hoisted the second is non standard
FunctionStatement and will be created during execution time and will
replace the value of `foo' with newly created function.
And of course here is some quirks behavior and some implementation
interpret FS as FD, but this is out of my example.
For those who are interested in this topic, Jury has written great article:
http://kangax.github.com/nfe/>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] JSMentors - logo designer
Miller Medeiros: > why not create some sort of contest? I and Rey thought about it. The our idea was to create competition and giving the vote to members of JSMentors. We are able to create a page with proposed logos, their authors and ideas behind the design. The problem is that, while we are non commercial organization, we are not able to give money prize to winner. As I said, the name of creator will be in the main site of JSMentors and there will be link to the page of the designer. Samuel's logo seems OK for me. (If anyone other post attachment here, I will create a contest page) Samuel is it OK for you that? -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] JSMentors - logo designer
JSMentors is looking for logo designer who is able to create the logo of JSMentors. While we are not commercial organization, we are not able to pay for this. We are only able to add the name of the creator at the main site of JSMentors: http://jsmentors.com> If someone is interested please let me know. You can write in the thread or contact me via email: asen.bozhilov [at] gmail [dot] com -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] Technical discussion - Do not be too rude or too sensitive
When we launched the JSMentors the our goal was to provide place where we can share the our opinion and knowledge in Javascript and browser scripting. Here are welcome any level developers. We achieved these goals and the moment JSMentors has over 1200 members who are different level developers. Also at the moment JSMentors has really good threads which are helpful for every Javascript developers. The mentors and others share them knowledge and the list has valuable information. Meanwhile there are not some helpful threads. For example in the last week were posted two threads which were provocative. "JavaScript must die" "Today, Web Development Sucks" IMHO those threads don't improve the our knowledge and both allow for provocative disputes. I don't know was the goal of the author of those threads. He can pointed out. In the technical discussion it is normal some of the participants to be rude. As we have written, if there are any personal insults at the list, we are going to delete particular member who made those insults. On the other hand some members are sensitive on rude posts. While I really don't like rude posts, also it's not so good to be too sensitive. Sensitive people got only the rude part of the post and sometimes they miss the technical part. I think we should be concentrate on the technical discussion. Please don't be rude! This is a technical discussion. Also please don't be too sensitive on some rude posts. Just ignore them and especially the author. If you have any complaints about the behavior of particular member, please send an email to me or Rey Bango. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] localStorage - special setter and getter
Juriy Zaytsev :
> But is it a bug really? As far as I know, web storage spec (
> http://dev.w3.org/html5/webstorage/) makes no clarification on whether
> interface members are writable; or enumerable/configurable for that matter.
> WebIDL spec, however, does mention something about interface members having
> attributes { [[Writable]]: true, [[Configurable]]: false, [[Enumerable]]:
> false } (http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces).
Thanks for the links and the info.
> So it seems like writability of localStorage's getItem, setItem, clear, etc.
> is actually in accordance to spec... which is probably not that great, since
> it only makes for a more fragile implementation. The opposite argument could
> be that [[writable]]: false would disallow "useful" cases of overwriting
> localStorage methods, whatever those cases might be.
The problem is that they are not actually localStorage's methods. They
are inherited trough the prototype chain from `Storage' interface.
localStorage.setItem('foo', 'bar');
localStorage.getItem = null;
localStorage.getItem('foo'); //TypeError
localStorage.__proto__.getItem.call(localStorage, 'foo'); //bar
The setter in this case shadows `getItem' in the prototype chain and
here IMHO internal attributes wouldn't help a lot, while
`localStorage' instance hasn't own property `getItem'.
I think they have to specified the setter and getter of Storage instances.
Another interesting part of `localStorage' are integer properties. For
example getter with integer is mimic of `localStorage.key(n)';
localStorage.setItem('foo', 'bar');
localStorage[0]; //returns foo
localStorage[21]; //throws an Error with message: Index or size is
negative or greater than the allowed amount
localStorage[-1];
This is about the getter, the more interesting part is. Could set an
item which key is integer digit?
localStorage.setItem('10', 'bar');
localStorage.hasOwnProperty('10'); //true
localStorage[10]; //Error try to get the 10th key instead of item with key 10
localStorage.getItem('10'); //bar
Another example using regular setter instead of `setItem':
localStorage[666] = 'bar'; //There is not any errors here
localStorage.getItem(666); //bar
localStorage[666]; //Error
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] JavaScript must die
cancel bubble: > Thoughts? If you have a hummer and hit in your head. Does it mean this a problem of hummer? -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] localStorage - special setter and getter
The last week I explored some things about `localStorage'. The most
interesting and meanwhile confusing things are described in two
articles about `localStorage':
http://www.bennadel.com/blog/2105-Exploring-HTML5-s-localStorage-Persistent-Client-Side-Key-Value-Pairs.htm>
http://hacks.mozilla.org/2009/06/localstorage/>
"The easiest way to use localStorage is to treat it like a regular object:"
After reading these articles I start thinking about the setter and
getter of storage instance referred by `window.localStorage'. The
others questions are:
Should I treat `localStorage' as a regular object?
Does it safe if I do?
So I did some tests, to answer on my questions.
The test cases are in Firefox 3.6 under Debian.
What happens with `localStorage' object when I put new item in
associated list trough `setItem' method?
var hasOwnP = Object.prototype.hasOwnProperty,
storage = window.localStorage;
storage.clear(); //Clear associated list
storage.setItem('foo', 'bar');
console.log(hasOwnP.call(storage, 'foo')); //true
console.log(storage.getItem('foo')); //bar
storage.setItem('setItem', 'bar');
console.log(hasOwnP.call(storage, 'setItem')); //false
console.log(storage.getItem('setItem')); //bar
console.log(typeof storage.setItem); //function
storage.setItem('hasOwnProperty', 'bar');
console.log(hasOwnP.call(storage, 'hasOwnProperty')); //false
console.log(storage.getItem('hasOwnProperty')); //bar
console.log(typeof storage.hasOwnProperty); //function
Obviously `setItem' checks the prototype chain of `localStorage' for
passed key. If key exist it does not add new own property to
`localStorage' object. Just put this key/value in associated list. The
interesting part is if passed key does not exist in the prototype
chain of `localStorage', then it creates new own property of
`localStorage' and put key/value in associated list.
Everything seems safe and clear, but what happens if I treat this
object as "regular" object?
var hasOwnP = Object.prototype.hasOwnProperty,
storage = window.localStorage;
storage.clear(); //Clear associated list
storage.setItem = 'bar';
console.log(hasOwnP.call(storage, 'setItem')); //true
console.log(storage.getItem('setItem')); //bar
console.log(typeof storage.setItem); //string
storage.hasOwnProperty = 'bar';
console.log(hasOwnP.call(storage, 'hasOwnProperty')); //true
console.log(storage.getItem('hasOwnProperty')); //bar
console.log(typeof storage.hasOwnProperty); //string
Now the setter does not check for existence of these properties names
in the prototype chain of `localStorage'. It directly add them as own
properties and also add them as key in associated list with this
storage instance.
This answer on my two questions and the answer is, it's not really
safe to treat `localStorage' as regular object. When I have to add
key/value in the list I should use `setItem' method.
Lets see the getter:
var hasOwnP = Object.prototype.hasOwnProperty,
storage = window.localStorage;
storage.clear(); //Clear associated list
storage.setItem('foo', 'bar');
console.log(storage.getItem('foo')); //bar as expected
console.log(typeof storage.foo); //string as expected
storage.setItem('setItem', 'bar');
console.log(storage.getItem('setItem')); //bar as expected
console.log(typeof storage.setItem); //function "unexpected"
As I explained when `setItem' has called with `key` which exist as
property name in the prototype chain of `localStorage' it will not
create new own property name of `localStorage' with this name. From
this point comes the "unexpected" result.
While in my example it's not really unexpected result, it can be if
there are third party extensions of `Object.prototype', because
`localStorage' inherit from `Object.prototype'.
var hasOwnP = Object.prototype.hasOwnProperty,
storage = window.localStorage;
storage.clear();
Object.prototype.foo = function () {};
storage.setItem('foo', 'bar');
console.log(storage.getItem('foo')); //bar as expected
console.log(typeof storage.foo); //function
Hope this thread makes some clarifications the members of JSMentors!
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] JSFiddle as a requirement (was: Addressing DOM)
אריה גלזר : > BTW - if any of you find other tools more comfortable - like jsbin - that's > fine too, my point is t separate code from message I am not sure how this is helpful. With Rey we are working on posting guidelines and of course there will be point about code posting. Third parties tool are not good for me. The posted code there can be expired and this will break consistency of the discussion. I do not think someone should post ton of code. If he post only the relevant part it can be easy for the members of group to read and give relevant responses. I agree with Stefan about consistency of the discussion and personally I prefer code to be a part of a message. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Can I dynamically make a prototype link?
Juriy Zaytsev wrote: Is Brendan on this list? Unfortunately he is not at the list. I've sent invitation to him, be he hasn't replied yet. I hope he would join at the list. Also Douglas Crockford would accept and his invitation. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Re: Introductions
Garrett Smith wrote: On 12/18/10, Marc Harter wrote: My name is Marc Harter (@wavded). I'm stationed in Eau Claire, WI and work with JavaScript daily. Very glad this list is here, was turned off by c.l.js spam and trolling Can't remember seeing any posts from you there. If you interpret a post as being abusive, don't be afraid to mention that, e.g. "hey that sounds insulting." Easier said than done; just try not to get into the flames. I've gotten mails in the past like "you're an asshole" when the person who wrote that was replying to my criticism. C.l.js isn't all bad. Try and make a good post or two there and make it better! I replied on similar question at the previous list: http://jsmentors.com/archive/jsmentors_jsmentors.com/2010-December/000491.html> The goal of the list is *not* to blame c.l.js or the major Javascript libraries. From c.l.js I have learned a lot of things from professional developers. Although there are some trollish posts, there is and really valuable information. How someone would interpret this information depends on his opinion and his attitude. Some people do not like to be target of criticisms. This really depends on the criticisms and on the critics. When the criticism is constructive and says some things which can improve your knowledge and especially your code it is really good for you (I know you agree with this statement). The problem is that some people do not skip invaluable criticisms and start to reply of trollish posts. While they do not skip the troll's criticism, they completely skip the constructive criticism. They think all of the critics are trolls, which does not help them a lot. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Can I dynamically make a prototype link?
Garrett Smith wrote:
Juriy Zaytsev wrote:
var beget = (function() {
function F(){ };
All good except for the extra empty statement there. AYK, semicolon is
not needed after the FD.
I guess this is typo according knowledge of Juriy. Anyway, more
important is discussion about setter of `__proto__'. Setter of internal
[[Prototype]] is not a good idea. Breandan has pointed out this topic
before. At least setter of [[Prototype]] is not very good from
performance. This setter needs to check for cycling prototype chain. If
there is not a finite prototype chain it should throw an error. For
example:
var x = {};
x.__proto__ = x;
This design allows to be created reference cycle, because we have a
reference to created object trough the scope chain. In this case it must
be checked for reference cycle. But in this case:
var x = {
__proto__ : someObject
};
This is pretty safe to be used in object literal, because when you
assign value of `__proto__' you have not got any references to created
object via object literal.
var x = {
__proto__ : x //x is undefined here
};
From this point of view, this object literal is similar as
`Object.create' method introduced by ECMA-262-5. `Object.create' is
factory method and this allows for optimizations. There is not any
reasons for checking reference cycle, because it cannot be created at all.
`__proto__' has and some side effects in SpiderMonkey, but we have
discussed them many times at c.l.js
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] What's the best way to implement Object Inheritance?
qwertypants:
> I'm a bit new to Object Inheritance in JavaScript and I'd like to find
> the best way to do so. I have seen a few techniques from Resig to
> Crockford, but I'd like to know the simplest and most effective way to
> create object from existing ones. Is there any native way that this
> can be done elegantly? Am I going to have to create a function to
> create my objects using something like Crockford's beget method?
I think you first should read what is the architecture of objects and
inheritance in Javascript.
https://developer.mozilla.org/en/JavaScript/Guide/Inheritance_Revisited>
http://dmitrysoshnikov.com/ecmascript/chapter-7-1-oop-general-theory/>
http://dmitrysoshnikov.com/ecmascript/chapter-7-2-oop-ecmascript-implementation/>
After reading these, you will be able to decide which approach is
better according your requirements.
> For example, I'm using Raphael.js to construct a circle Object that
> I'd like other Objects to inherit from:
>
> var Circle = function(){
> return {
> type: "circle",
> x: 0,
> y: 0,
> cx: 31,
> cy: 32,
> r: 1,
> fill: "#00AEEF"
> }
> }
> To get a new instance of it, I'm using this:
> var inner = new Circle;
At all you don't need to use `new` keyword here, unless you want to
create new native object by the internal [[Construct]] method of
`Circle'. The worst part of this design is that on every instance you
are going to allocate memory for whole interface of this object.
Trough the prototype chain is definitely better to be done this. For
example:
function F() {
}
F.prototype = {
constructor : F,
foo : function () {
},
bar : function () {
}
};
var instance1 = new F,
instance2 = new F;
instance1.foo();
instance2.foo();
instance1.foo === F.prototype.foo; //true
instance2.foo === F.prototype.foo; //true
So both instance inherit properties trough the their prototype chain
from `F.prototype'. The prototype chain for example of `instance1` is:
instance1 -> F.prototype -> Object.prototype -> null
The prototype chain is a list of objects. This list of object is
formed by internal property [[Prototype]] which every native object
has it. While this property is internal you are not able to access it
or overwrite its value. Some implementations provide non-standard
property `__proto__` which is exactly mimic of internal [[Prototype]].
For example:
instance1.__proto__ === F.prototype; //true
instance1.__proto__.__proto__ === Object.prototype; //true
instance1.__proto__.__proto__.__proto__ === null; //true
In normal case the end of prototype chain is always
`Object.prototype`. Its [[Prototype]] value is `null' which marks the
end of the prototype chain. It is important for resolving properties
against the prototype chain.
Another problem of presented approach from you is `instanceof'.
inner instanceof Circle; //false
While `inner' has not reference to `Circle.prototype' in its prototype
chain, `instanceof` will return `false`.
Read the resources which I gave you, there is enough information.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Please unsubscribe me
Diogo Baeder : > Guy, > > Sorry to bother you again with this, but I really can't unsubscribe with > this > e-mail, because there's no Google Account with it (but I keep receiving the > group messages in it). I've got another account in Google (@gmail), and > that's > the one I'm using to read the group messages. You were unsubscribed. Next time when you have similar question please contact me via email: asen.bozhilov [at] gmail [dot] com -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Javascript Quizz
Chris Williams wrote: Asen, When you review the quiz, it outputs "errors with #1, #2..." but there aren't numbers next to the quiz items, which makes it hard to determine 1) if I did all of them and 2) which I got wrong. thoughts on adding numbers? It is strange. What kind of browser are you using? I've used ordered list and my Firefox 3.6 on Debian displays correctly the order of items. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] eval indirect call (this.eval)
JSDude wrote:
this.eval — as I understand right is Reference, where
ReferenceName is eval. I'm always think that this is global eval
because it's evaling in context window.
The simple answer on your question is:
eval('...');
The evaluation of MemberExpression return Reference which in abstract
view looks:
var reference = {
base : GlobalEnvironmentRecord,
referencedName : 'eval',
strictReference : false
};
While in:
this.eval('...');
var reference = {
base : GlobalObject,
referencedName : 'eval',
strictReference : false
};
So per first rule for direct call of `eval' defined in:
15.1.2.1.1 Direct Call to Eval:
The Reference that is the result of evaluating the MemberExpression in
the CallExpression has an environment
record as its base value and its reference name is "eval".
You should read "10 Executable Code and Execution Contexts" and you will
find the answer.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Javascript Quizz
Christophe Porteneuve wrote: • Dmitry: http://dmitry.baranovskiy.com/post/91403200 (answers explained in another post, linked to by Juriy's quizz, but no peeking!) • Juriy: http://perfectionkills.com/javascript-quiz/ Have "fun" %-) I've made JS quiz before. http://asenbozhilov.com/articles/quiz.html> Enjoy, we can discuss the answers here. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] Workaround "this" ?
Peter Foti :
> function addEvent( obj, type, fn ) {
> if ( obj.attachEvent ) {
> obj['e'+type+fn] = fn;
> obj[type+fn] = function(){obj['e'+type+fn]( window.event );}
> obj.attachEvent( 'on'+type, obj[type+fn] );
> }
This is perfectly example of how you can setup circular reference
pattern, which cause memory leak in older IE.
Variable Object of addEvent -> obj -> obj[type+fn] ->
function[[Scope]] -> Variable Object of addEvent
You cannot prevent this leak. The only one unreliable way is to setup
unload handler which breaks this circular reference.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
Re: [JSMentors] What to Read to Get Up to Speed in JavaScript
Rey Bango: > What to Read to Get Up to Speed in JavaScript > http://blog.reybango.com/2010/12/15/what-to-read-to-get-up-to-speed-in-javascript/ I have categorized the number of online resources: http://asenbozhilov.com/resources.html> Soon when we start FAQ section of JSMentors it would be good if we maintain resources and certain books there. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
[JSMentors] Re: First test message
test test 2010/12/13, Rey Bango : > This is a test message >
