Closed danielpeintner closed 1 year ago
But we agreed earlier that ExposedThing objects can only be created from the factory methods. We have steps for constructing ExposedThing, used from the steps for the factory method produce()
, but those cannot be used in a JS constructor.
We can add bare-object JS constructors, but then we need to spec it accordingly, just creating the bare JS objects, but then we need a 2nd stage init (involving all async operations) like expanding the init dict to a TD. I think this might get confusing. It's cleaner to have a factory method.
For ConsumedThing it was a bit different, since the constructor only copied the init dict as TD internal slot, then all async ops were done in the methods. If we want to align, we can remove the constructor here, and use the pattern we follow with ExposedThing.
Removing the constructor from ConsumedThing
to align it with the ExposedThing
interface sounds reasonable to me. I assume the sections about constructing ConsumedThing
and ExposedThing
(e.g., https://w3c.github.io/wot-scripting-api/#constructing-exposedthing) should be kept even though the constructors are not exposed via the interfaces, right? Or should these sections also be removed?
The steps for constructing, well, for producing (since they are created by a factory method) will remain in the spec, and they belong to the consume()
and produce()
steps. But if the order of introducing concepts makes it more readable, we can factor out the construction steps and describe them later. I am thinking to rename these from "Constructing" to "Create" in order to avoid possible confusion with constructors.
Call Nov 07
see https://github.com/w3c/wot-scripting-api/pull/515