The `implements` operator should work on instances too

[Jamesernator]

From the updated explainer, I just noticed that implements is used to compare a constructor with a protocol. I don't understand why this is operating on constructors and not on instances, and what the use case for this behavior is.

Like if we had for example an Iterable protocol, it seems far more useful to be able to check whether individual objects implement such a protocol e.g.:

protocol Iterable { /* ... */ }

protocol ArrayLike { /* ... */ }

function toArray(obj: Iterable | ArrayLike) {
    if (obj implements Iterable) {
        // collect from iterator
    } else if (obj implements ArrayLike) {
        // loop over indices
    } else {
        throw new TypeError(`can't convert to array`);
    }
}

While we can solve this for at least classes by using obj.constructor instead, there is no guarantee that an arbitrary object even has a .constructor property or even a non-null prototype, but it still might otherwise have all protocol members.

It seems unfortunate to tie protocols specifically to classes, as people might well want anonymous (i.e. ordinary) objects that would otherwise have all protocol members.

[LeaVerou]

I agree it would be useful to be able to implement protocols on plain objects and check instances.
This also adds another use case to the imperative implements() constraint I proposed in #4 (comment) (check numeric properties).

One challenge is how to handle static members. Do we just check obj.constructor, regardless of what it may contain? Do we just ignore them if the object is not a function? Something else?

[ljharb]

implements should act on any object. a promise implements Thenable. an iterable implements Iterable. etc.

"a class" isn't a thing, really - class is mostly just sugar for defining a constructor function and a prototype object. Promise implements Thenable is false, but new Promise() implements Thenable is true.

[LeaVerou]

@ljharb I agree, but the semantics need to be well-defined, see above.

There's also the question of whether Protocol.implement() should work on regular objects (ideally, I think it should), and how static members behave in that case if so.

[michaelficarra]

This issue has kind of overlapped with #58 starting at #58 (comment). Not sure how we should resolve that to consolidate the conversation.

[ljharb]

I think it will be a much more important and common question "does this object someone gave me implement a given protocol?" rather than "does an arbitrary constructor (or .constructor off of a random object, which may not even be present) implement a given protocol?", but per #58 (comment) I think we should have both.

[LeaVerou]

Would branching based on whether .prototype exists or not be a terrible solution?

• If .prototype exists: Check requires on .prototype and requiresStatic on self
• If it doesn't: Check requires on self and requiresStatic on .constructor, iff one exists (to cover Object.create(null))

This seems to cover most use cases I can think of rn. There's the open question of how to handle a regular (non-constructor) function, which can be used both as an object and as a constructor. With the algorithm above it would always be treated as a constructor with no way out, which I'm not super happy about.

[ljharb]

That wouldn't work if you wanted to test if a constructor itself implements a protocol - for example, Map implements SymbolSpeciesable.

[LeaVerou]

That wouldn't work if you wanted to test if a constructor itself implements a protocol - for example, Map implements SymbolSpeciesable.

Why not? It would go to the first branch, which is exactly what we want:

If .prototype exists: Check provides on .prototype and providesStatic on self

[ljharb]

because it's the Map function itself, not Map instances, that implements that particular protocol.

I suppose the protocol could be written to have it as a static member, though, that's true.

[michaelficarra]

No, we cannot branch between the two behaviours. It is reasonable both to want to ask about whether instances of this constructor will implement a protocol or whether the constructor itself implements a protocol. There's no way to use the exact same operator to do both.

[LeaVerou]

@ljharb

because it's the Map function itself, not Map instances, that implements that particular protocol.

Yes? None of what I wrote above assumed the latter.

I suppose the protocol could be written to have it as a static member, though, that's true.

How else would it have it? But also, it doesn't need to? In both cases of what I described, there are two objects being checked, one for each category of required members (requires and requiresStatic).

---

@michaelficarra Fair. Though no good syntax to do both springs to mind. :/

[michaelficarra]

It feels like if we're going to have static required/provided members in protocols and we're going to have an implements operator, it'd be appropriate for that operator to validate both the static and non-static members, which means the LHS should be a constructor. It's somewhat unfortunate because I also agree with @ljharb that the more common operation would be testing an instance on the LHS. But the operator reads misleadingly if it's only checking part of what the protocol actually describes. ... Should we drop static protocol members?