[Syntax Sugar Proposal] Provide object keyword and support inheritance, a thought about static methods cannot be rewritten

💡 Ideas
1

Hello, thank you for watching. Please forgive me for the shortcomings in the following content. I would like to share a discussion about the syntax of the inherited object keyword. The pseudo code is as follows:

object Parent {
name = 'parent'
echoName(){
console.log(this.name)
}
}
object Child extends Parent{
name = 'child'
}

Parent.echoName() //parent
Child.echoName() //child

The following is an explanation of the source of this proposal idea. I often use static methods in program development. Compared with ordinary functions, static methods have better static prompts and module distinction functions. However, I encountered a problem, that is, static methods cannot be inherited and rewritten. This is a unified design specification in the language I am familiar with. However, in the development process, this does lead to inconvenience. There is a website called Zhihu in China about [Why not use all static methods in Java? 】, this topic has caused widespread discussion. Some people think that using all static syntax is not enough for OOP, while others think that this method does bring enough efficiency improvement to development and improves the development experience.

Many people have encountered the same problem as me, that is, when using static development, abstract parent classes are needed. When methods are reused, static cannot be rewritten, which reduces development efficiency.

However, due to the special logic of static, it seems inappropriate to support rewriting of static methods.

So can a new keyword, object, be supported to implement this function?

Object has the function of class, can be integrated by class, can be inherited by object, and can be used directly.

Regarding OOP content, there are more practical applications in Java and Kotlin, so please allow me to use Java as an example to illustrate. In Java In web development, the spring framework is an unavoidable framework. Object instances managed by spring are all singletons, which means that a class will only have one instance. This is the case in most cases. However, in this case, we need to declare a class first, and then instantiate this class to get the object. This process is a bit cumbersome. We can merge these two steps into one step, that is, declare an object with type hints and use it immediately.

In kotlin, there is the object keyword syntax. The following code can be run in kotlin

object ParentObject {
var name = "ParentObject"
fun echoName() = "name:${name}"
}

// Use
fun main() {
println(ParentObject.echoName()) // Output: ParentObject
}

And kotlin's object supports inheritance from class, but it does not support inheritance from object, which still cannot solve the problem I encountered at the beginning

So I would like to ask if it is possible to support this function in js

Looking forward to your answer, thank you very much

2

Although kotlin supports the object keyword, the objects created by the object keyword in kotlin do not support inheritance by objects created by other object keywords. So I also submitted a proposal to kotlin. The proposal address is https://youtrack.jetbrains.com/issue/KT-72809/proposalObjects-created-with-the-object-keyword-can-be-extends.
Thanks for reading

If the post I posted contains incorrect content, please correct me. If there are serious errors in the content of this post, I apologize.Thank you.

3

We can already write the following:

let Parent = {
  name: 'parent',
  echoName() { console.log(this.name); }  
}

let Child = {
  __proto__: Parent,
  name: 'child',
};

Parent.echoName() //parent
Child.echoName() //child

How is what you're suggesting different than this?

2 Likes
4

Hi, isn't proto marked as deprecated?

I think the difference between them is like the implementation of type and extends before the class keyword and the difference between the implementation of class and extends keywords.

I imagine the object keyword is the syntax sugar of class + new, like the following

class Parent {
    name = 'parent'

    echoName() {
        console.log('parentEcho:' + this.name);
    }
}

class Child extends Parent {
    name = 'child'

    echoName() {
        console.log('childEcho:' + this.name);
        super.echoName()
    }
}

const parent = new Parent()
const child = new Child()

parent.echoName()
child.echoName()

object keyword omitted class declaration and new

object Parent {
    name = 'parent'
    echoName() {
        console.log('parentEcho:' + this.name);
    }
}

object Child extends Parent {
    name = 'child'

    echoName() {
        console.log('childEcho:' + this.name);
        super.echoName()
    }
}

Parent.echoName()
Child.echoName()

As for the advantages, whether it can have better type hints, I am not sure. I understand that the object keyword is the syntactic sugar of class+new. I personally think that the reason for its existence is similar to the reason for the existence of the class keyword. Before es6, there was no class and extends keywords, and similar functions could be achieved, but class and extends keywords were still introduced.

5

Only the object.__proto__ form, where you're using it to access or set the prototype after creating an object. The syntax in object literals is standard and not deprecated.

The reason for the introduction of the class and extends keywords is that there was not previously a declarative way to make a class. You could do it imperatively, by setting Object.setPrototypeOf(Foo.prototype, Bar.prototype) etc, but imperative code is generally less clear than declarative.

But __proto__ already exists and is declarative, so there's no real advantage to adding another new kind of syntax here.

6

Okay, I understand. Thank you for your answer, it is very useful and I have learned a lot.

7

No, the __proto__ syntax in an object literal is not deprecated at all; it's the Object.prototype accessor/mutator that's normative optional, that you might be thinking of.

8

Yes, I thought they were the same thing, I misunderstood, thanks for reminding me

9

This is a common misunderstanding, and not surprising given their similarity. Perhaps this could be documented more clearly somewhere.

10

This is already documented in both Object initializer - JavaScript | MDN and Object.prototype.__proto__ - JavaScript | MDN in (IMO) visible places, so I hope it suffices.

11

I was thinking of making it more visible. The warning blocks dominate compared to the plain paragraph text.

For example the very first part of the page could say "not to be confused with the use of __proto__ in object literal syntax".

2 Likes