Correct Use Of The JavaScript Interface Keyword

First of all, no, I'm not trying to create any sort of Java-like interface for my JavaScript code. I've seen those questions all over, and while I'm still a relative novice to Java

Solution 1:

Okay, so as with other answers, you know that the keyword interface has no real use case in Javascript world, yet.

Your Math example made me suspicous that you are talking about a design pattern, called Module Pattern, widely used for scoping Javascript code. There are many ways of making your code modular. For example just like OddDev answered you , the famous Prototype Pattern can embed your code in a modular fashion (just like your Math example). Here is the Revealing Prototype Pattern example with also private variables and functions for additional flexibility:

/* Example from: 
    http://www.innoarchitech.com/scalable-maintainable-javascript-modules */
var myPrototypeModule = (function (){

   var privateVar = "Alex Castrounis",
       count = 0;

   function PrototypeModule(name){
    this.name = name;
   }

   function privateFunction() {
      console.log( "Name:" + privateVar );
      count++;
   }

   PrototypeModule.prototype.setName = function(strName){
      this.name = strName;
   };

   PrototypeModule.prototype.getName = function(){
      privateFunction();
   };

   return PrototypeModule;     
})();

but that is not all. Other options include Scoped module pattern, POJO module pattern and many more. Have a look at How to Write Highly Scalable and Maintainable JavaScript: Modules, it has a very simple and yet thorough set of examples.

So far, we talked about plain Javascript. If you have the ability to use libraries in your code, then amazing set of libraries such as Requirejs, CommonsJS are there to help you on this with out-of-the-box functionalities. Have a look at Addy Osmani's post about Writing Modular JavaScript With AMD, CommonJS & ES Harmony.

Solution 2:

The interface keyword in javascript is a FutureReservedWord, so it does absolutely nothing right now, though that may change in the future specifications. (See ECMAScript 5.1, section 7.6.1.2). In the ES6 draft, this is also the same.

As for you module, this is a perfectly idiomatic solution. It is always a good idea to "namespace" your functions, as it keeps the global scope as clean as possible.

Solution 3:

I believe (and may be totally wrong) that these are there to provide a means for the definers of the language to enforce a set of behaviors to be implemented in various JS engines. Is that correct?

No, this is not correct. Things like "Math" etc. are objects containing functions. If you use for eyample "Math.pow(...)" you just execute the function stored in the "Math" object. Check this example:

var Math = {};
Math.prototype.pow = function(){
 alert("stuff");
}

var ShapeInspections = { isSymmetrical: function (s) { // determine if shape is symmetrical }, numAngles: function (s) { // return the number of angles } } A purely contrived example, but is it anti-idomatic to name the "module" this way?

It's okay to name your objects like this. As already discussed "Math" is also just an object and follows these naming conventions.

To make things clear for the interface keyword:

The following tokens are also considered to be FutureReservedWords when they occur within strict mode code (see 10.1.1). The occurrence of any of these tokens within strict mode code in any context where the occurrence of a FutureReservedWord would produce an error must also produce an equivalent error:

implements let private public yield interface package protected static

It's just reserved cause it's "may" needed in the future. So don't worry too much about it :) http://www.ecma-international.org/ecma-262/5.1/#sec-7.6

Solution 4:

Do not confuse the "interfaces" that are specified in IDL with the interface keyword.

The latter is reserved for potential future use, but is not yet actually used in ECMAScript (not even in ES6).