Kari  Kihn

Kari Kihn

1592191020

ES2019 Features: What Even Are They? by Tara Z. Manicsic

Thankfully, every year ECMAScript gives us new shinies to advance how we code JavaScript. I’ve found myself digging into features & proposals ever since my curiosity of ES2017’s SharedArrayBuffer took me down a fascinating rabbit hole. Let’s delve into some of the features & proposals we get to look forward to in 2019.

https://2019.jsconf.eu/tara-z-manicsic/es2019-features-what-even-are-they.html

#javascript

What is GEEK

Buddha Community

ES2019 Features: What Even Are They? by Tara Z. Manicsic
Dylan  Iqbal

Dylan Iqbal

1630996646

A Look at an ES2022 Feature: Class Static Initialization Blocks

ECMAScript class static initialization blocks

Class static blocks provide a mechanism to perform additional static initialization during class definition evaluation.

This is not intended as a replacement for public fields, as they provide useful information for static analysis tools and are a valid target for decorators. Rather, this is intended to augment existing use cases and enable new use cases not currently handled by that proposal.

Status

Stage: 4
Champion: Ron Buckton (@rbuckton)

For detailed status of this proposal see TODO, below.

Authors

  • Ron Buckton (@rbuckton)

Motivations

The current proposals for static fields and static private fields provide a mechanism to perform per-field initialization of the static-side of a class during ClassDefinitionEvaluation, however there are some cases that cannot be covered easily. For example, if you need to evaluate statements during initialization (such as try..catch), or set two fields from a single value, you have to perform that logic outside of the class definition.

// without static blocks:
class C {
  static x = ...;
  static y;
  static z;
}

try {
  const obj = doSomethingWith(C.x);
  C.y = obj.y
  C.z = obj.z;
}
catch {
  C.y = ...;
  C.z = ...;
}

// with static blocks:
class C {
  static x = ...;
  static y;
  static z;
  static {
    try {
      const obj = doSomethingWith(this.x);
      this.y = obj.y;
      this.z = obj.z;
    }
    catch {
      this.y = ...;
      this.z = ...;
    }
  }
}

In addition, there are cases where information sharing needs to occur between a class with an instance private field and another class or function declared in the same scope.

Static blocks provide an opportunity to evaluate statements in the context of the current class declaration, with privileged access to private state (be they instance-private or static-private):

let getX;

export class C {
  #x
  constructor(x) {
    this.#x = { data: x };
  }

  static {
    // getX has privileged access to #x
    getX = (obj) => obj.#x;
  }
}

export function readXData(obj) {
  return getX(obj).data;
}

Relation to "Private Declarations"

The Private Declarations proposal also intends to address the issue of privileged access between two classes, by lifting the private name out of the class declaration and into the enclosing scope. While there is some overlap in that respect, private declarations do not solve the issue of multi-step static initialization without potentially exposing a private name to the outer scope purely for initialization purposes:

// with private declarations
private #z; // exposed purely for post-declaration initialization
class C {
  static y;
  static outer #z;
}
const obj = ...;
C.y = obj.y;
C.#z = obj.z;

// with static block
class C {
  static y;
  static #z; // not exposed outside of class
  static {
    const obj = ...;
    this.y = obj.y;
    this.#z = obj.z;
  }
}

In addition, Private Declarations expose a private name that potentially allows both read and write access to shared private state when read-only access might be desireable. To work around this with private declarations requires additional complexity (though there is a similar cost for static{} as well):

// with private declarations
private #zRead;
class C {
  #z = ...; // only writable inside of the class
  get #zRead() { return this.#z; } // wrapper needed to ensure read-only access
}

// with static
let zRead;
class C {
  #z = ...; // only writable inside of the class
  static { zRead = obj => obj.#z; } // callback needed to ensure read-only access
}

In the long run, however, there is nothing that prevents these two proposals from working side-by-side:

private #shared;
class C {
  static outer #shared;
  static #local;
  static {
    const obj = ...;
    this.#shared = obj.shared;
    this.#local = obj.local;
  }
}
class D {
  method() {
    C.#shared; // ok
    C.#local; // no access
  }
}

Prior Art

Syntax

class C {
  static {
    // statements
  }
}

Semantics

  • A static {} initialization block creates a new lexical scope (e.g. var, function, and block-scoped declarations are local to the static {} initialization block. This lexical scope is nested within the lexical scope of the class body (granting privileged access to instance private state for the class).
  • A class may have any number of static {} initialization blocks in its class body.
  • static {} initialization blocks are evaluated in document order interleaved with static field initializers.
  • A static {} initialization block may not have decorators (instead you would decorate the class itself).
  • When evaluated, a static {} initialization block's this receiver is the constructor object of the class (as with static field initializers).
  • It is a Syntax Error to reference arguments from within a static {} initialization block.
  • It is a Syntax Error to include a SuperCall (i.e., super()) from within a static {} initialization block.
  • A static {} initialization block may contain SuperProperty references as a means to access or invoke static members on a base class that may have been overridden by the derived class containing the static {} initialization block.
  • A static {} initialization block should be represented as an independent stack frame in debuggers and exception traces.

Examples

// "friend" access (same module)
let A, B;
{
  let friendA;

  A = class A {
    #x;

    static {
        friendA = {
          getX(obj) { return obj.#x },
          setX(obj, value) { obj.#x = value }
        };
    }
  };

  B = class B {
    constructor(a) {
      const x = friendA.getX(a); // ok
      friendA.setX(a, x); // ok
    }
  };
}

References

TODO

The following is a high-level list of tasks to progress through each stage of the TC39 proposal process:

Stage 1 Entrance Criteria

  • Identified a "champion" who will advance the addition.
  • Prose outlining the problem or need and the general shape of a solution.
  • Illustrative examples of usage.
  • High-level API.

Stage 2 Entrance Criteria

Stage 3 Entrance Criteria

Stage 4 Entrance Criteria

For up-to-date information on Stage 4 criteria, check: #48

  • Test262 acceptance tests have been written for mainline usage scenarios and merged.
  • Two compatible implementations which pass the acceptance tests:
  • A pull request has been sent to tc39/ecma262 with the integrated spec text.
  • The ECMAScript editor has signed off on the pull request.

Download Details:
Author: tc39
The Demo/Documentation: View The Demo/Documentation
Download Link: Download The Source Code
Official Website: https://github.com/tc39/proposal-class-static-block 
License: BSD-3
#javascript #es2022 #ecmascript 

Kari  Kihn

Kari Kihn

1592191020

ES2019 Features: What Even Are They? by Tara Z. Manicsic

Thankfully, every year ECMAScript gives us new shinies to advance how we code JavaScript. I’ve found myself digging into features & proposals ever since my curiosity of ES2017’s SharedArrayBuffer took me down a fascinating rabbit hole. Let’s delve into some of the features & proposals we get to look forward to in 2019.

https://2019.jsconf.eu/tara-z-manicsic/es2019-features-what-even-are-they.html

#javascript

Loma  Baumbach

Loma Baumbach

1600476300

Getting Started With Feature Flags

Introduction

As any developer can tell you, deploying any code carries technical risk. Software might crash or bugs might emerge. Deploying features carries additional user-related risk. Users might hate the new features or run into account management issues. With traditional deployments, all of this risk is absorbed at once.

Feature flags give developers the ability to separate these risks, dealing with one at a time. They can put the new code into production, see how that goes, and then turn on the features later once it’s clear the code is working as expected.


What is a Feature Flag?

Simply put, a feature flag is a way to change a piece of software’s functionality without changing and re-deploying its code. Feature flags involve creating a powerful “if statement” surrounding some chunk of functionality in software (pockets of source code).


The History of Feature Flags

Leading Web 2.0 companies with platforms and services that must maintain performance among high traffic levels led the way in regard to developing and popularizing new deployment techniques. Facebook, in particular, is known as a pioneer of feature flags and for releasing massive amounts of code at scale. While building its massive social network more than a decade ago, the company realized that its uptime and scale requirements could not be met with traditional site maintenance approaches. (A message saying the site was down while they deployed version 3.0 was not going to cut it).

Instead, Facebook just quietly rolled out a never-ending stream of updates without fanfare. Day to day, the site changed in subtle ways, adding and refining functionality. At the time, this was a mean feat of engineering. Other tech titans such as Uber and Netflix developed similar deployment capabilities as well.

The feature flag was philosophically fundamental to this development and set the standard for modern deployment maturity used by leading organizations everywhere today. Recently, feature flags have been used in tandem with continuous delivery (CD) tools to help forward-looking organizations bring features, rather than releases, to market more quickly.

#devops #continuous integration #ci/cd #continous delivery #feature flags #flags #feature branching #feature delivery

Tinder Features: A complete and in-detail list

There are a wide number of dating apps around the world, but only Tinder became successful. Do you know the reason for its success? The primary reason why tinder is able to attract users around the globe is because of its simple yet attractive features.

Due to distinct features along with the highly-interactive UI UX, millions of users are getting attracted to this dating app.

Do you want to know the features present in the most popular dating app in the world, then we have got you covered. Here, we have made an exclusive list of all the Tinder Features.

#Tinder Features #Tinder gold features #Tinder App Features

Feature Engineering & Feature Selection

WarningThere is no magical formula or Holy Grail here, though a new world might open the door for you.


📈Python for finance series

  1. Identifying Outliers
  2. Identifying Outliers — Part Two
  3. Identifying Outliers — Part Three
  4. Stylized Facts
  5. Feature Engineering & Feature Selection
  6. Data Transformation

Following up the previous posts in these series, this time we are going to explore a real Technical Analysis (TA) in the financial market. For a very long time, I have been fascinated by the inner logic of TA called Volume Spread Analysis (VSA). I have found no articles on applying modern Machine learning on this time proving long-lasting technique. Here I am trying to throw out a minnow to catch a whale. If I could make some noise in this field, it was worth the time I spent on this article.

Especially, after I read David H. Weis’s Trades About to Happen, in his book he described:

“Instead of analyzing an array of indicators or algorithms, you should be able to listen to what any market says about itself.”¹

To closely listen to the market, as also well said from this quote below, just as it may not be possible to predict the future, it is also hard to neglect things about to happen. The key is to capture what is about to happen and follow the flow.

Image for post

But how to perceive things about to happen, a statement made long ago by Richard Wyckoff gives some clues:

“Successful tape reading [chart reading] is a study of Force. It requires ability to judge which side has the greatest pulling power and one must have the courage to go with that side. There are critical points which occur in each swing just as in the life of a business or of an individual. At these junctures it seems as though a feather’s weight on either side would determine the immediate trend. Any one who can spot these points has much to win and little to lose.”²

#feature-engineering #feature-selection #trading #python #machine-learning