Bringing back ObjC would be great. We could generate several bug fixes to keep it going a few more years. Is there more documentation about the test infrastructure? I didn't see much more than the read me, but I could dig into it more.
Kevin On Mon, Apr 22, 2019 at 10:01 AM James E. King III <jk...@apache.org> wrote: > Releases for this project are very expensive. We have about 28 > languages to support. It would make more sense to reinstate the objc > code for the next major release if people are still using it and the > premise that everybody is moving to Swift was in fact unfounded. In a > project this complex, removing unused languages is one way to reduce > the maintenance burden, which is why it was removed. With more active > participants, that is less necessary. It would also be helpful if we > had people actively maintaining it, and if we had cross language test > support to make sure it was actually working. > > - Jim > > On Mon, Apr 22, 2019 at 10:42 AM Kevin Wojniak <kwojn...@box.com.invalid> > wrote: > > > > 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. > > > > > > > > >
