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
Is your feature request related to a problem? Please describe.
Changes to the naming of some WarpClient APIs have made them out of sync with the naming of the same APIs in SwimJava packages. The APIs in question are WarpClient.syncs, (used to be "keepSynced"), WarpClient.relinks (used to be "keepLinked"), WarpClient.sync() (sounds like a declarative action but is actually a getter/setter for the syncs property), WarpClient.link() (sounds like a declarative action but is actually a getter/setter for the relinks property)
Describe the solution you'd like
Change the names of the APIs back to what they were before so they may be consistent across platforms.
Describe alternatives you've considered
We could keep the current naming, which is different from SwimJava's, but I don't see a benefit for it. The contributor who takes on this issue should try and figure out what they original reason for renaming the APIs was.
Additional context
A PR for this issue must be accompanied by a matching PR with corresponding updates to Swim Docs.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Changes to the naming of some WarpClient APIs have made them out of sync with the naming of the same APIs in SwimJava packages. The APIs in question are
WarpClient.syncs
, (used to be "keepSynced"),WarpClient.relinks
(used to be "keepLinked"),WarpClient.sync()
(sounds like a declarative action but is actually a getter/setter for thesyncs
property),WarpClient.link()
(sounds like a declarative action but is actually a getter/setter for therelinks
property)Describe the solution you'd like
Change the names of the APIs back to what they were before so they may be consistent across platforms.
Describe alternatives you've considered
We could keep the current naming, which is different from SwimJava's, but I don't see a benefit for it. The contributor who takes on this issue should try and figure out what they original reason for renaming the APIs was.
Additional context
A PR for this issue must be accompanied by a matching PR with corresponding updates to Swim Docs.
The text was updated successfully, but these errors were encountered: