WebIDL interfaces should only be used when you have both data and behavior

[domenic]

I see a lot of classes that have only data, or have only behavior. Both of these cases should be represented by plain JS objects.

---

Edit by TAG: Current TAG thinking here

[marcoscaceres]

I guess you will explain this a bit, but can you give me a quick tl;dr example/why behavior-only interfaces should be represented as JS objects? Not really getting what you mean.

[domenic]

Sure. If there's no state to mutate, then it's just a bunch of functions. (Note: functions, not methods.) And we represent a collection of named functions in JS by e.g. { foo: function () { ... }, bar: function () { ... } }, not by declaring a class with those functions as methods, and then creating an instance of that class, and then calling the instance's methods.

[marcoscaceres]

Thanks for the clarification, @domenic. It would indeed be nice to be able to express this somehow in WebIDL.

There is something that does worry me tho: It's usually pretty clear when you are returning "data" objects, but I think it gets trickier to design objects that are purely behavioral - as it's easy to add accessor properties on them. Having them as classes makes it easier to allow others to extend them (either directly through the prototype or through extends proper).

[domenic]

I see what you're saying. However, in my experience, the behavior-only objects in web specs are usually pretty clear: they're often singletons, and often have only one or two functions. As such, a shared prototype is not useful anyway in those cases, reinforcing the idea that a class is not the right tool for the job.

[dbaron]

Should WebIDL namespaces be used for the behavior-only case?

[travisleithead]

@dbaron that makes sense to me.

• data-only objects => dictionary
• behavior-only objects (functions only) => namespace
• mix of behavior and data (where the object holds state) => class (interface)