You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Kevin Wojniak <kw...@box.com.INVALID> on 2019/04/21 23:55:27 UTC
Re: Objective-C support
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 <ed...@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 <st...@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.
>
Re: Objective-C support
Posted by Kevin Wojniak <kw...@box.com.INVALID>.
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 <kw...@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 <kwojniak@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 <
> 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 <st...@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.
> > > > >
> > >
>
Re: Objective-C support
Posted by "James E. King III" <jk...@apache.org>.
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 <kw...@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 <kw...@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 <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 <st...@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.
> > > >
> >
Re: Objective-C support
Posted by Kevin Wojniak <kw...@box.com.INVALID>.
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 <kw...@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 <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 <st...@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.
> > >
>
Re: Objective-C support
Posted by "James E. King III" <jk...@apache.org>.
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 <kw...@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 <ed...@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 <st...@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.
> >