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
We shouldn't have used type aliases in types (see for example OperatorId). See quote below.
Problem it creates is that when another pkg uses the sdk and calls a function which returns an Aliased type, vscode (and probably other editors?) show the returned type as the underneath type definition (instead of the type alias name).
So for eg getOperatorsAvsStateAtBlock will show
instead of its actual definition in the sdk as
Note the key type is Bytes32 instead of OperatorId, so it lost its semantics.
Type aliases are not meant for everyday use. They were introduced to support gradual code repair while moving a type between packages during large-scale refactoring. Codebase Refactoring (with help from Go) covers this in detail.
We shouldn't have used type aliases in types (see for example OperatorId). See quote below.
Problem it creates is that when another pkg uses the sdk and calls a function which returns an Aliased type, vscode (and probably other editors?) show the returned type as the underneath type definition (instead of the type alias name).
So for eg getOperatorsAvsStateAtBlock will show
instead of its actual definition in the sdk as
Note the key type is Bytes32 instead of OperatorId, so it lost its semantics.
From https://yourbasic.org/golang/type-alias/ (and see the linked https://go.dev/talks/2016/refactor.article)
The text was updated successfully, but these errors were encountered: