Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #34775

Re: No need for IIFEs any more?

Newsgroups comp.lang.javascript
Date 2018-03-13 13:27 -0700
References <1c492da9-76d8-4c70-8c73-1c6e2f8baa23@googlegroups.com>
Message-ID <8356a1cf-b575-4e12-bd59-070c0331b5c2@googlegroups.com> (permalink)
Subject Re: No need for IIFEs any more?
From "Michael Haufe (TNO)" <tno@thenewobjective.com>

Show all headers | View raw


RobG wrote:
> Since block scoped variables were introduced in ECMAScript 2015, it's been possible to implement the same "private variable" functionality as is available using the IIFE pattern.
> 
> E.g.
> 
>   // Using an IIFE  
>   var getNext = (function() {
>     var i = 0;
>     return function() {
>       return i++;
>     };
>   }
>   
>   console.log(getNext()); // 0
>   console.log(getNext()); // 1
>   
>   // Using block scope
>   {
>     let i = 0;
>     var getNext = function() {
>       return i++;
>     }
>   }
>   
>   console.log(getNext()); // 0
>   console.log(getNext()); // 1
> 
> There are some quirks here:
> 
>  - Function declarations inside blocks are available outside the block, but only in non–strict mode. 
>  - Safari has a bug in non-strict mode in that if *getNext* uses a function declaration, the closure with *i* isn't preserved, so a reference error results when the function is called.
>  - Safari is inconsistent with other major browsers in non-strict mode where function declarations inside blocks are "hoisted", whereas in others they aren't.
>  - Variable declarations using *var* are available outside the block in both strict and non-strict mode, hence the use of a function expression so the code can be used in either mode (and to avoid the Safari bug).
>  - Using block+var+function expression means functions are only available after the statement that assigns them to the variable
> 
> Therefore it seems that the block+var+function expressions pattern (BVFE?) can be a replacement for IIFEs, as they provide provide consistent results across current implementations in either mode, though I haven't tested that widely.
> 
> So:
> 
>  1. Are there any features of IIFEs that can't be easily replaced by a block?
> 
>  2. Are there any quirks to be aware of (other than those noted above)?
> 
>  3. Can blocks be used to replace IIFEs?
> 

Why not use some other modern features such as lambdas and default parameters?

<script>
var getNext = ((i = 0) => 
  () => i++
)();

`${getNext()},${getNext()}`  /* 0,1 */
</script>

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

No need for IIFEs any more? RobG <rgqld@iinet.net.au> - 2018-03-12 21:42 -0700
  Re: No need for IIFEs any more? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-03-13 13:27 -0700
    Re: No need for IIFEs any more? RobG <rgqld@iinet.net.au> - 2018-03-15 21:47 -0700
  Re: No need for IIFEs any more? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2018-03-13 18:43 -0300
    Re: No need for IIFEs any more? RobG <rgqld@iinet.net.au> - 2018-03-15 21:54 -0700

csiph-web