You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/02/28 20:02:45 UTC

[jira] [Commented] (THRIFT-3773) Swift Library

    [ https://issues.apache.org/jira/browse/THRIFT-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15888775#comment-15888775 ] 

ASF GitHub Bot commented on THRIFT-3773:
----------------------------------------

Github user apocolipse commented on the issue:

    https://github.com/apache/thrift/pull/1084
  
    Update 2/28/2017:
    Old Swift generator and new merged into one,
    Old generator under `cocoa` option, `promise_kit` option only available for old generator as well.
    
    I don't have any Swift 2.x projects so i can't really test, but if anyone else wants to spot check code and test against old versions that'd be great.  I've left the old swift generator CC file in tact (moved to `*.cc..old`), and spaced out things such that it lines up with the new code line for line for comparison.
    
    Next and last steps to make this production ready IMO is namespacing, I'm going to add an option to namespace by splitting into subdirectories.  Actually configuring projects will be left up to the developer.  I'll add some output describing how to do it in SPM, but injecting the targets into SPM or Xcodeproj are beyond the scope of Thrift so for now the only thing namespacing will do is place source files in their own namespace relative directory, generate imports when necessary, and appropriately namespace types.  Any suggestions or input are welcome.


> Swift Library
> -------------
>
>                 Key: THRIFT-3773
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3773
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Swift - Library
>            Reporter: Thomas Bartelmess
>            Assignee: Chris Simpson
>
> We already have the option to generate Swift code in the Cocoa compiler, however large parts of the (Objective-C) Cocoa Library still depend on Cocoa and  Objective-C.
> It would be good to have a native Swift library that doesn't depend on the Cocoa libraries.
> Design goals:
> - Fully compatible with the code that is currently generated by the Cocoa compiler (both Objective-C and Swift).
> - Ability to run on Linux
> - Pure Swift, no Objective-C code.
> - No dependencies on closed source apple libraries
> - Keep the same interface, so that the library is compatible with the code the current cocoa compiler generates
> - Better server support that the current Objective-C library.
> - Follow the new Swift packaging format to be compatible with the Swift Package manager



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)