Joined January 2014
·

Brian Vanderbusch

Normal Gravity
·
Bloomington, Illinois, United States
·
·
·

A tip for anyone reading this comment, powerline was unified, and is no longer under lokaltog, and is now under Powerline/powerline. Aside from swapping out that one Bundle instruction for the new destination, everything else looks good still (as of time of comment.)

Posted to JavaScript - Module pattern over 1 year ago

Trolling? Trying to help you is trolling? And did you think I wouldn't notice when you literally replaced your entire article, and instead of thanking those who tried to help, you called them trolls, and then threw the source links for your plagiarism in our faces. You changed the property names of the demonstrations in Todd's article and put your name on it.

This community will help you if you don't call them trolls and give them and be rude (what you basically did to @benjamine), and you wouldn't have been scorned for fixing your own work.

Posted to JavaScript - Module pattern over 1 year ago

In Javascript, closures create scopes. Scopes are a stateful thing. Encapsulation is not. You can have something that seems encapsulated, but in truth what you have is a state that no longer exists and it's members are no longer accessible because it doesn't exist.

"These libraries are not my interest in what I want to show"

They're not libraries, they're patterns for js module development And what you are trying to show is an incorrect implementation of the module pattern.

Several experienced developers have tried to tell you in polite ways that you're doing it wrong. But now I'm just going to say it. You don't have a strong enough grasp of the language to be putting forth educational material. This can cause problems to those who read it and trust that you DO know what you are talking about, when in fact you don't.

You're pumping out harmful educational material faster than those trying to help you can point out the flaws, and you continue with new material despite being informed that your existing material is incorrect.

Posted to JavaScript *this* keyword over 1 year ago

If you take the concepts you demonstrate in this article with scope, and remember them in a few of your other articles, you'll be able to address the issues I pointed out. You use this appropriately here, but in some other articles you have the behavior of this described incorrectly.

Start here (use kfwerf's suggestion also, and expand this basic understanding out to edit your other tips, and you'll be on track.

Posted to JavaScript Constructors over 1 year ago

You really don't understand what you're doing. Your first 4 functions are the same (could be hotswapped with no differences in the calling code. The 5th... well it's set up to allow you to be different, but you don't actually take advantage of it. (It's the first one where you put yourself in a position to use scope to create a closure, but but returning every property in an object, you are doing the same thing as returning this.

none of this uses closures, and for that matter, "fixed" isn't fixed. if i is 4 when the first function evaluates due to the asynchronous processing nature of js... and you pass that same value of i and assign it to safe_i, then safe_i will now have the same problem you had with i. The key is to create a scope context when the code is executed, not when it's compiled... and you're not doing that. That is commonly done by returning a function which is then executed when the outer function is executed, and that function was compiled with the value of i based on the index of the iteration you are executing.

with your first set of examples, you aren't really doing anything other than creating an anonymous function in the global namespace. nothing is encapsulated (this is still the same context inside and outside the function), it's just difficult to access because it's not named.

Posted to JavaScript - Module pattern over 1 year ago

Closure and encapsulation are not the same thing, and closures do not store the scope at the time of execution, then have a scope collection reference and a local scope collection at the time of compilation. by the time execution comes around, it's a whole 'nuther ball game.

Posted to JavaScript - Using Namespaces over 1 year ago

This creates a lot of overhead in the system, and isn't really doing anything like what namespaces do in object oriented languages. ThisThe industry best practice is to use commonJS style module definitions.

var MyCompany.MyModule =(function module(window, undefined, dependency){
           // assign values and methods to exports using exports.myValueOrMethod 
           return exports;
}(window, undefined, dependency))

To anyone who reads this, I missed a piece of punctuation or (9) that caused my code formatting to be off in the examples of the service. I have a gist that I've updated here: https://gist.github.com/LongLiveCHIEF/4c5432d1c2fb2fdf937d

Posted to Move repo from bitbucket to github over 1 year ago

This won't transfer wiki's/issues/comments etc... just the repo and history

Achievements
66 Karma
4,516 Total ProTip Views