Comments (4)
Hi @ilijapuaca!
projects such as this one are only there to bridge the gap and allow us to use frameworks of the future today
Not really, the first goal I had in mind when starting this project was to provide a compatible implementation for Linux so it could be used in server-side Swift development.
having those devices run Combine instead would (almost surely) be a performance gain
Being able to leverage Apple's Combine whenever it is available would indeed be great, but the thing is that clients who link against the latest SDK (which includes Combine, hence canImport(Combine)
evaluates to true
) but back-deploy to older OS versions without Combine are forced by the compiler to perform runtime checks like if #available(iOS 13.0)
to actually use any of those Combine APIs. Conditional compilation that you propose to use is simply not enough.
On a side-note, is there Slack organization or anything alike set up somewhere? It could be helpful seeing that many things are still up in the air, and discussing those there could likely be more efficient and keep issue list clean(er).
No, there's no Slack organization. There has been no need, since there are only two active contributors right now. We use GitHub Projects to track development.
from opencombine.
I think it would be useful to have a slack channel. I'm currently on the ios-developers.io slack as spadafiva if you hairy to be on there.
I'm looking forward to working with you.
-Joe
from opencombine.
projects such as this one are only there to bridge the gap and allow us to use frameworks of the future today
Not really, the first goal I had in mind when starting this project was to provide a compatible implementation for Linux so it could be used in server-side Swift development.
I keep forgetting that they didn't make Combine available on Linux (did you find any source about why this is the case?), I assume they'll do it at some point but that's a good point, there's definitely some value there.
having those devices run Combine instead would (almost surely) be a performance gain
Being able to leverage Apple's Combine whenever it is available would indeed be great, but the thing is that clients who link against the latest SDK (which includes Combine, hence canImport(Combine) evaluates to true) but back-deploy to older OS versions without Combine are forced by the compiler to perform runtime checks like if #available(iOS 13.0) to actually use any of those Combine APIs. Conditional compilation that you propose to use is simply not enough.
I see... I haven't tried this myself, and that would indeed be annoying to do. Do you see any other way in which this could be achieved while hiding the implementation details from developer?
@spadafiva I tried joining the workspace, but I'm getting error on their website, I assume something is broken. I'll jump on there once they fix it. Perhaps we can start a private channel on there?
from opencombine.
I've created a Slack workspace.
from opencombine.
Related Issues (20)
- the `*` in DispatchQueue scheduler's SchedulerTimeType gives wrong value HOT 3
- Ready for production? HOT 3
- [Consideration] Bridge from OpenCombine to Combine publishers HOT 12
- Slack Invite is no longer valid HOT 1
- Doesn't compile on macOS Monterey / XCode 13 HOT 2
- [Feature Request] Async Publisher.values HOT 1
- Re-enable concurrency tests on Wasm when swiftwasm supports them
- Re-enable concurrency tests on Windows when Windows issues are fixed
- error HOT 5
- [Bug]The Publishers.ReceiveOn may lead to subscriber never receive the published single when schedule is concurrent queue.
- [Bug]The Publishers.ReceiveOn may lead to subscriber never receive the published signal when scheduler is concurrent queue.
- would be nice to be able to use "@Published" directive in earlier Swift versions that do not know it HOT 2
- Add primary associated type support HOT 1
- Unable to build on Ubuntu 22.04.1 HOT 2
- Zip crash HOT 3
- When BUILD_LIBRARY_FOR_DISTRIBUTION is set to YES, the build will fail. HOT 1
- Xcode 15 crash HOT 1
- EXC_BAD_ACCESS when repeatedly using Future HOT 3
- When Future call Cancel, why parent is copied by take()?
- error build: Undefined symbol: _OBJC_CLASS_$
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opencombine.