Instead of bringing back the objc code and fully supporting it going forward, what about releasing one or more 0.12 minor updates to fix a few bugs in the objc code? I can make issues and PRs for the changes.
Kevin On Mon, Apr 22, 2019 at 5:51 AM James E. King III <jk...@apache.org> wrote: > There should be no incompatibilities if both sides are using binary > protocol, for example, since that format has been very stable. > We haven't expressly done cross-version testing in our CI however the > compatibility should work. > > We also need someone to write the TestClient and TestServer for swift > so it can be part of our cross-language test suite. > > - Jim > > On Sun, Apr 21, 2019 at 7:55 PM Kevin Wojniak <kwojn...@box.com.invalid> > wrote: > > > > Hi Jim, > > > > Sorry for the delay in responding. Other tasks have taken priority! > > > > Cocoa is Apple specific, but there is GNUstep, however that is not widely > > used. I do notice the existing Swift port is still using the Cocoa > > libraries, and seems to be a direct, although incomplete, port from the > > Objective-C sources. The "Cocoa" version should be called Objective-C > > (objc), if it ever is brought back, for clarity. > > > > One thing to note about the existing Swift implementation is still using > > NSFileHandle in TSocketServer, which unfortunately handles read and write > > errors by throwing Objective-C exceptions (since it's actually written in > > Objective-C). However, Swift cannot natively catch Objective-C errors, so > > the current code is broken, and on error with crash the process. One > needs > > to write a wrapper in Objective-C (easy enough in the bridging header) > and > > handle this in Swift. The 0.12 Objective-C actually misses a few of these > > exceptions as well. > > > > While Swift can be used in Objective-C, one needs to use a subset of > Swift > > features publicly to properly interface with Obj-C, so unless there are > > Objective-C tests for Swift, the Swift codebase will eventually (if not > > already) become unusable in Objective-C. > > > > Our big concern, and it doesn't seem to be documented anywhere (unless I > > missed it), is if it's safe to use (for example) Thrift 0.12 Python > process > > to talk to a Thrift 0.9 Objective-C process. We assumed this wouldn't be, > > and didn't want to take any risks. > > > > Thanks, > > Kevin > > > > > > On Mon, Mar 25, 2019 at 5:38 AM James E. King III <jk...@apache.org> > wrote: > > > > > Hi, > > > > > > The consensus was that cocoa has been deprecated since 2012, nobody was > > > actively > > > pushing it forward, it was never integrated into the cross-language > > > integration test suite, > > > and the project has support for 28 languages and limited resources to > > > do that. Given the > > > long deprecation time and various internet discussions, and that > > > nobody spoke up on the > > > developer mailing list. This discussion happened only on the dev > > > mailing list, which was > > > clearly an error on my part. > > > > > > If there is significant community support and folks want to get > > > involved in actively maintaining it, > > > we can open a discussion about that. We haven't released 0.13.0 yet > > > so there isn't a release > > > where it has been removed. At the time, folks who actively work on > > > the project agreed that > > > OSX development future is Swift, and folks ought to be moving towards > > > Swift. You can > > > continue to use 0.12.0 with cocoa support for your cocoa projects. It > > > will still be compatible > > > with future thrift releases. > > > > > > Is there a way to run cocoa on linux? If so, integrating it and swift > > > into the cross-language > > > test framework is one of the top priorities to ensuring language > > > support stays alive. > > > > > > Those are the reasons why it happened. > > > > > > Thanks, > > > > > > Jim (PMC Member) > > > > > > > > > On Sat, Mar 23, 2019 at 2:25 PM Edward Capriolo <edlinuxg...@gmail.com > > > > > wrote: > > > > > > > > In general doesn't objective-c have a wider scope then swift anyway. > Like > > > > swift is targeted for mac but you can compile objective-c with gcc > on any > > > > nix? > > > > > > > > On Friday, March 22, 2019, Steve Yegge <steve.ye...@gmail.com> > wrote: > > > > > > > > > I'd like to second this. I have a large Objective-C app that > won't be > > > > > ported to Swift in the next few years. > > > > > > > > > > > > > > > On Fri, Mar 22, 2019 at 1:54 PM Kevin Wojniak > <kwojn...@box.com.invalid > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I am curious as to why the Objective-C implementation was > removed, > > > since > > > > > > Objective-C is not a deprecated language. The documentation says > to > > > use > > > > > > Swift. However, Swift is not fully backwards compatible with > > > Objective-C. > > > > > > Also, bringing in Swift to Objective-C means bringing in the > entire > > > Swift > > > > > > runtime, which is not always desired. > > > > > > > > > > > > I noticed the Objective-C implementation of Thrift was upgraded > to > > > modern > > > > > > syntax which significantly improves the usage in Swift. This > system > > > works > > > > > > well for both Objective-C and Swift clients. > > > > > > > > > > > > We still use Thrift with Swift and Objective-C code bases and > don't > > > have > > > > > > plans on porting Objective-C to Swift. However we do need to > upgrade > > > our > > > > > > Python usage of Thrift, which is why we're looking at upgrading > our > > > > > Thrift > > > > > > usage across multiple languages (C# and C++). > > > > > > > > > > > > Are there major issues with the Objective-C implementation? I'd > be > > > open > > > > > to > > > > > > helping keep it alive. A few things I'd like to see improved: > > > > > > - Use native number types instead of NSNumber. In 0.9 this > worked, > > > but > > > > > > regressed in later versions. > > > > > > - Correct nullability usage. Some methods are declared non-null > but > > > can > > > > > > return nil, which prevents proper error handling in Swift and can > > > lead to > > > > > > segfaults > > > > > > - Improve type safety by replacing some "id" instances with > > > > > "instancetype" > > > > > > > > > > > > Thanks, > > > > > > Kevin > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sorry this was sent from mobile. Will do less grammar and spell check > > > than > > > > usual. > > > >
