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.
