> Oh, it wasn't clear to me that we really want to have static members. > I may be biased here, but I always viewed static members as just a > poor man's substitute for a proper module system. Fortunately, it > looks like we will have a real one instead!
I'm sympathetic to that view, but statics also have precedent in JS, so I would bet people will continue to use them. I think it's not unreasonable to want a declarative way to create members of the constructor function object. That said, in the interest of parsimony, if we had to start cutting, statics would probably be one of the first I'd eliminate. > To be honest, I'm a bit worried that there will be a _lot_ of semantic > redundancy in the end. After adding modules + classes + static members > (+ traits?), there would be at least three or four different, > complicated constructs that evaluate to some kind of object, with > significant functional overlap. I think "modules are a construct that evaluates to an object" is the wrong way to think about them. Syntactic modules are a second-class construct that is not an expression. You can reflect on modules at runtime, and that reflection is provided as an object, but that's because almost all compound data structures in JS are objects. But I would advise against describing modules as a kind of object. And I think an important aspect of classes is that they are providing a declarative convenience for doing things that people *already* do with objects in JS today. So I'm not as worried about redundancy here. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
