thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Wojniak <kwojn...@box.com.INVALID>
Subject Re: Objective-C support
Date Sun, 21 Apr 2019 23:55:27 GMT
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 <jking@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 <edlinuxguru@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.yegge@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 <kwojniak@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message