You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each of these methods meets the criteria for being an attribute (https://w3ctag.github.io/design-principles/#attributes-vs-methods), and are const once the MLOperand is constructed. Is we are to have an accessor on MLOperand for each key in the MLOperandDescriptor which created it, then these should be readonly attributes.
That being said, once we open this can of worms, there are several options we could choose from:
This is my preferred option. Unfortunately, JavaScript dictionaries are not read-only so (unless we want to push to introduce FrozenDictionary) we should use a getter.
MLOperandDescriptor takes a dimensions field, while querying this field from an MLOperand is done with the shape() method. As per https://w3ctag.github.io/design-principles/#attribute-reuse, we should re-use terms rather than unnecessarily introducing new vocabulary.
A quick CTRL-F of the spec text shows:
139 instances of "dimensions", mostly due to MLOperandDescriptor.dimensions
483 instances of "shape", which seems to be used more commonly in prose (e.g. "the shape of the input tensor")
We should decide to use one or the other (and possibly continue this discussion on another issue regardless)
I agree that we should do (3) regardless. Filed #669 to track that
Also filed #670 to track making MLOperandDescriptor.dimensions frozen. We should do this anyways, but especially if we're providing a getter that returns an MLOperandDescriptor then it would be nice if the array was frozen!
Given those expected improvements, my preference is (1)
The
MLOperand
interface looks like:Each of these methods meets the criteria for being an attribute (https://w3ctag.github.io/design-principles/#attributes-vs-methods), and are const once the
MLOperand
is constructed. Is we are to have an accessor onMLOperand
for each key in theMLOperandDescriptor
which created it, then these should bereadonly attribute
s.That being said, once we open this can of worms, there are several options we could choose from:
1. Getter which returns an
MLOperandDescriptor
This is my preferred option. Unfortunately, JavaScript dictionaries are not read-only so (unless we want to push to introduce
FrozenDictionary
) we should use a getter.2. Naive conversion to
readonly attribute
Seems reasonable. But why have an attribute called
shape
which refers to the same thing asMLOperandDescriptor.dimensions
?3. Rename
shape
todimensions
, or vice versaMLOperandDescriptor
takes adimensions
field, while querying this field from anMLOperand
is done with theshape()
method. As per https://w3ctag.github.io/design-principles/#attribute-reuse, we should re-use terms rather than unnecessarily introducing new vocabulary.A quick CTRL-F of the spec text shows:
MLOperandDescriptor.dimensions
We should decide to use one or the other (and possibly continue this discussion on another issue regardless)
4. Make
MLOperandDescriptor
aninterface
This is my least favorite, but I figured I'd list this here for completeness.
The text was updated successfully, but these errors were encountered: