class literal

💡 Ideas
1

class literal

Description

Instantiates the given constructor with this being the appended object literal

Syntax

[Function Constructor]{ Object Literal }

Summary

  • Instantiate classes using object literals with named properties.
  • Use class fields to set defaults.
  • Constructors become a legacy way to instantiate objects, or rather just a simple way of performing data validation & satisfying other cross cutting concerns
Working Equivalent
{foo:"hello"} Object{foo:"hello"}
new Dog("Bob") Dog{owner:"Bob"}

Advantages :

  • Draws a clear line between classes and functions, just at a glance using this syntax you clearly get the distinction between "entity with properties" and "pure input/output function" as opposed to the "new" syntax often hinting that it's both and neither at the same time
  • Improves readability by naming parameters directly at the point of creation once instead of lining it in an array and reassigning the same value up to 5 times
  • Promotes the use of classes as clear separate entities with public mutable properties, private runtime states and functional methods
  • Ability to switch to similar classes using the spread syntax : Cat{...bobs_dog}

Exemple :

Gearing up some payload with utilities :

function class class literal
HTML(src).tags.find(....) new HTML(src).tags.find(...) HTML{src}.tags.find(...)
Most likely losing on performance. Confusing as to exactly what it returns. Must redefine the same value 3 to 5 times. Write at least 3 extra lines of pure constructor bloat at the source. Awfully verbose with not only the function syntax but also the added "new" babbling, very confusing. Best performance, best readability, no constructor, least extra code, beautiful marriage between functionality definition and argument name, classes become literal joy to use.
Worst performance, bad readability especially when returning an object with a state Worst readability, extra bloat Best readability, best performance, least amount of code

Wrapping up

This proposal goes against the new public class fields, as it adds the final piece to the ongoing "remove the need to ever use a constructor" work, it also makes great sense for class literals to define the properties firsthand to have class fields come in second as a lovely way to fill in the defaults. Finally and if one desires to do so, constructors would still be there as a fallback if one really needs to perform side effects or input validation.

2

"Readability" here is subjective; i find the new version vastly more readable than either of the other two.

Can you elaborate on why you think a "class literal" - which would have to do precisely the same thing that new does - would have better performance than new? At best, I'd think it would have equal performance.

What about newlines? Would the constructor name have to be followed, without a space, by a {? What about those who would find that aesthetically objectionable (hi!) and would prefer ClassName {? What about those who would want a newline between the constructor name and the {?

Classes are a function - class is just syntax for producing a constructor function with a prototype. Does new not already draw a clear line between pure and constructed functions?

Stage 1 of TC39's process is "we agree this is a problem worth solving". What problem are you solving here?

1 Like
3

This proposal seems to be in the spirit of the <| Set Literal [[prototype]] Operator, that's what I like about it :-)

However, just like @ljharb I don't understand what exactly your syntax would do, or why you think it could do that faster. From what I gather, you would have the expression

Dog { owner: "Bob" }

be equivalent to

Object.assign(new Dog, { owner: "Bob" })

Is that correct?

4

What problem are you solving here?

this assumption is the problem :

Classes are a function

I argue that classes are not functions, classes are templates being assigned to blank objects

I argue that the concept of instantiating classes through functions exists solely out of necessity to assign each argument to a key

the class literal proposal introduces a new way of instantiating a class
that is, simply by appending an object literal to the class
the constructor is still called albeit without arguments, and this refers to the appended object instead of creating a blank one

everything else works as expected except for class public fields
class public fields would behave as function argument defaults, as to not override a property defined by the object literal

class Foo{
    bar = "default"
    bool = true
    constructor(){
      console.log(this.bar); // "hello world!"
      console.log(this.leet); // leet(){}
      console.log(this.bool); // true
    }
    leet(){}
}

const foo = Foo{ bar:"hello world!" }

This proposal removes the curse of having to write boilerplate constructors and comes out as a blessing on the other end as the class instantiation process experiences a complete shift in perspective whereby classes are no longer authoritative functions making an object using opaque key value pairs from an array of arguments but rather templates augmenting your object.

This proposal follows the same syntax as the tagged template literal whereby a function is appended a template literal.

I do not expect enhancing runtime performance through this proposal, this is a matter of removing class constructor overhead and enhancing readability.