[AIT-124] Proposal for how the path-based API will look in Swift#128
[AIT-124] Proposal for how the path-based API will look in Swift#128lawrence-forooghian wants to merge 34 commits into
Conversation
Preparation for trying to add the public path-based API from JS, whilst still being able to use `swift build` to check that the API itself compiles.
The latest commit on the integration/objects-breaking-api (i.e. path-based API) branch at the moment. Will remove stuff from here as it's migrated to Swift.
It's now only used as an input to operations
now that it's only input people shouldn't need to query these Note that we don't have an output equivalent any more
This document was generated by Claude; take with a pinch of salt. But the gist seems to be what I was expecting — that not _much_ has changed; largest thing is the changes to the compaction APIs, which we have an issue to track.
Again, Claude-authored with my input; lightly reviewed.
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
This is some work that I did in December last year, to decide how to port the JS path-based API to Swift. We never finalised the design due to shifting priorities. Now it's May 2026 and we're planning to start working on this, so I've revisited it and added some further notes.
Here's what's here (bullet points written by Claude):
PATH-BASED-API.md— notes (written by me) recording the design decisions made when porting the JS path-based API to Swift.PATH-BASED-API-MAIN-DELTA.md(written by Claude) — what's changed inliveobjects.d.tson ably-jsmain(tip498d26dfat time of writing) since this proposal was based on ably-js at0bdd674— the LiveObjects types have since moved out ofably.d.tsinto a dedicatedliveobjects.d.ts, and the new LODR-057compact()/compactJson()split landed. The doc lists the action items the proposal needs to absorb, plus the bits that can be ignored (REST API, batch context).PATH-BASED-API-JAVA-PYTHON-COMPARISON.md(written by Claude) — how this Swift proposal compares to the parallel Java / Python path-based API proposal in ably-java#1190 (reviewed at commitbe13cdc). Picks out the conversion-specific decisions (the ones not inherited from the cross-SDK path-based design) and notes where Swift and Java/Python diverge.The rest of the PR rewrites
Sources/AblyLiveObjects/Public/PublicTypes.swiftinto the proposed Swift surface and adds anexample.swiftdemonstrating the proposed usage.It's also worth listening to this Fellow call, in which we discuss the path-based API and some design decisions in porting it to Swift. (Stick around until the description of how I've handled cyclical references in the Swift compact object representation, but you don't need to listen to the final discussion about how to change the JS compact API because that's already been done in JS now.) [AIT-124] Sketch of how user-specified types might work in Swift #129 builds on the current PR to explore the codegen approach described in that call.
Related tickets
getRoot()(action item 2 in the delta doc)