Constructor signature design review / questions

[LeaVerou]

const Foldable = new Protocol({
  name: 'Foldable',
  extends: [ .. ],
  requires: {
    foldr: Symbol('Foldable.foldr'),
  },
  staticRequires: { .. },
  provides: {
    Object.getOwnPropertyDescriptors({
      toArray() { .. 1},
      get length() { .. },
      contains(eq, e) { .. },
    }),
    staticProvides: { ... },
  });

• Why would authors need to construct Symbol('Foldable.foldr') themselves? That seems antithetical to one of the core tenets of this feature (that you use symbols under the hood without defining them yourself) and introduces a disparity between the constructor and the declarative syntax (which A way to require different symbol fields than ProtocolName.* #48 would plug).
• provides accepting descriptors also introduces a disparity between the constructor and the declarative syntax, and requires boilerplate in the vast majority of cases. It also seems like a footgun: since the most natural syntax is to just include the object literal, I can easily see authors doing that. We could define that the feature copies descriptors from these objects, which gives you the best of both worlds (simple things are easy, complex things are possible) but is specifying descriptors actually desirable? E.g. class members are non-enumerable by default. Would protocol-provided members need to be specified as explicitly enumerable: false to behave the same way?
• Why is there a name field? What is it used for? Isn't const Foldable enough since everything is by reference?

[michaelficarra]

• Why would authors need to construct Symbol('Foldable.foldr') themselves?

This was my way of accommodating string-named required properties. But you're right, it's weird for the constructor not to create these for you in the common case. Considering #48, though, it seems like the appropriate amount of flexibility.

• provides accepting descriptors also introduces a disparity between the constructor and the declarative syntax, and requires boilerplate in the vast majority of cases. It also seems like a footgun

I agree. I think it'd be fine to just copy the descriptors off a provided object as you suggest. Or we could abandon that complexity and only support installing data properties and accessors in a very consistent way (non-enumerable, writable, configurable?). I'd actually lean toward that. Sometimes too much freedom allows people to do terrible things.

• Why is there a name field? What is it used for?

The name is optional and, if provided, included in the symbol descriptions for the symbols created for each provided method. Some of these questions can be answered by looking at the old runtime polyfill. Though, of course, nothing is set in stone yet.

[LeaVerou]

This was my way of accommodating string-named required properties. But you're right, it's weird for the constructor not to create these for you in the common case. Considering #48, though, it seems like the appropriate amount of flexibility.

In the spirit of making simple things easy and complex things possible, the minimum syntax required to declare intent is the symbol name for symbols that need to be generated for you, and the actual value for strings or other pre-existing symbols.

The declarative syntax does maintain this, so IMO it's strange to require this additional work for the imperative syntax. Also, the distinction between "existing symbol" and "symbol created by the protocol as a utility" seems useful to preserve.

Additionally, down the line we may want to require additional data per required member, e,g,. additional constraints, which is harder to retrofit in this API.

Just to brainstorm, what about instead of the value being the symbol, the value could be an object literal with various options? Then you could have a property or name (TBB) key if you want to provide the actual property (string or custom symbol) and one could always provide an empty object (or even undefined) to use the defaults (=creating a symbol). It does add a little more work to having strings as the required members, but that's probably a feature, not a bug :)

• provides accepting descriptors also introduces a disparity between the constructor and the declarative syntax, and requires boilerplate in the vast majority of cases. It also seems like a footgun

I agree. I think it'd be fine to just copy the descriptors off a provided object as you suggest. Or we could abandon that complexity and only support installing data properties and accessors in a very consistent way (non-enumerable, writable, configurable?). I'd actually lean toward that. Sometimes too much freedom allows people to do terrible things.

Again, in the spirit of simple things being easy and complex things being possible, IMO there should be an escape hatch for custom descriptors, even if it requires more work than the default, otherwise people still have to escape to hand-rolled solutions to cover their use cases. At least with classes you can always directly patch the constructor and prototype, but here there isn't even a way currently to directly manipulate these objects (until #55 is addressed).

However, there is another reason the "copy from object literal" idea is problematic: it seems reasonable that the default should be to mimic defining the provided properties directly in a class, …which is non-enumerable for accessors. However, object literal accessors are enumerable by default.

Perhaps the descriptors object is the lesser of two evils after all… It does make complex things possible, but not simple things easy, but I'm not sure the concentration of use cases is such that making simple things easy is sufficient by itself.

OTOH if #55 results in mutable protocols, then that's exactly the escape hatch we need, and we can just use a reasonable default here.

---

Another very minor point: I have a slight preference for requiresStatic/providesStatic over staticRequires/staticProvides. While both groupings are useful, I think it's slightly more useful to be able to see all constraints at once, and all provided API at once, so I'd put that first.

---

So, to sum up, the things that need consensus are:

1. How to make it possible to declare regular members without creating their symbols? (blocked on Are "foo" and foo distinct members? #59)
2. Descriptors or object literal for provided members? (blocked on How to access provided member implementations? #55)
3. Naming (see above)