make the design pattern one more JavaScript specific

[calvinmetcalf]

I find that 'Design Paten' discussions tend to be framed in terms of patterns that tend to need to be shoehorned into JavaScript awkwardly. (see prototype pattern) it might be a good idea to either add some discussion of this or judiciously edit the pattern entry to remove the more java centrist patterns that aren't helpful for discussions of JavaScript in favor of JavaScript centrist ones (e.g. callbacks and promises)

[KittyGiraudel]

I’d appreciate @virtyaluk’s opinion on this. :)

[virtyaluk]

@calvinmetcalf

I'm sorry, but I don't really understand what do you mean by saying

to remove the more java centrist patterns that aren't helpful for discussions of JavaScript.

All the patterns provided here are fully JavaScript specific. Basic terms of those may be applicable to other languages, though.

If you mean the article that goes by the name of Design Patterns, then you must know that this one is nothing but the general introduction to Design Patterns. The material provided by the article is the common knowledge of design pattern principles applicable to all the popular programming languages, not only JavaScript or Java. Besides, JS-specific patterns are linked to the local glossary articles, and all the rest are linked to the corresponding pages on the Wikipedia.

[calvinmetcalf]

by ' java centrist patterns that aren't helpful for discussions of JavaScript' I was thinking about ones like singleton ignores the fact that JavaScript has object literals so you'd never have code like that in reality.

e.g. an idiomatic version would be something like

var instance;
function singleton() {
  if (!instance) {
     instance = {
       method: function () {}
       data: data
    }
  }
  return instance;
}
function run() {
  var instance1 = singleton();
  var instance2 = singleton();

  console.assert(instance1 === instance2);
}

[virtyaluk]

Hey @calvinmetcalf!

I'm sorry, don't get me wrong, but I don't think you fully understand the concept of Singleton. I see your example is easier to understand and much simpler to use, and yeah, sure, it's one of the possible ways to implement the Singleton pattern. But, take a look what Wiki says about canonical implementation of the pattern:

Implementation of a singleton pattern must satisfy the single instance and global access principles. It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist.

I've also spent some time to find what authoritative developers say about it. As the result, I have the articles from the likes of Addy Osmani, Carl Danley, and Rob Dodson, whose own implementation is much like the one presented here, the one we have discussion about.

Thanks and have a nice day!

[calvinmetcalf]

I understand the idea, it's just that the canonical example uses Java, a language where the only way to create an object is via a class, compare to JavaScript which can make objects via object literal syntax.

I'd point out that Rob Dodson's article advocates simple doing

var NAMESPACE={};

I guess what I'm going for is that some of these design patterns especially when they are fairly literal transliterations of Java patterns are not very useful to a JavaScript discussion.

[KittyGiraudel]

So what’s the stand here? :)

[calvinmetcalf]

anyway my suggestion was just to make sure it's more javascript specific

[virtyaluk]

@calvinmetcalf I see you are more like old plain JS guy. It's nice. Really nice. But here's the thing. Since ES2015 JavaScript has classes and keeps moving forward in the real OOP direction, I guess. So, implementing patterns in JS using classes is the most appropriate way. Besides, if you have ever read Design Patterns you could be noticed that almost all the patterns are class based.

Ok. To avoid useless discussions I'm just saying you can submit any plain implementation (which has stood the test of time, if there's any) you want. It will help to show two sides of a coin: the old and the new way to achieve the desired result.

@HugoGiraudel I think we've got some consensus about the topic. If @calvinmetcalf have no other questions the issue can be closed.

Thanks!

[calvinmetcalf]

ok cool!