[
https://issues.apache.org/jira/browse/THRIFT-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428418#comment-16428418
]
ASF GitHub Bot commented on THRIFT-3773:
----------------------------------------
apocolipse commented on issue #1084: THRIFT-3773 Swift 3 Native Library
URL: https://github.com/apache/thrift/pull/1084#issuecomment-379278919
Hey @jeking3 I'll answer as best I can given i haven't done much with Thrift
in a while :) my coworker has taken up much of the Thrift work with Swift
internally at my company.
- No/Yes? The compiler is written to allow for the Old Cocoa/Swift with a
compiler flag, so anyone still using swift 1 or 2 should still be able to use
the Cocoa style generator but will have to use a compiler flag
- I don't believe thats documented anywhere
- No tests written for this, that is future work
- Should be exercisable in Travis though no tests currently
- I'm not sure where the Swift compiler support for Xenial and Artful
currently is, but should be available.
- Given backwards compatibility with Cocoa/Swift generator this should work
with all Swift versions v1 through v4
- LANGUAGES.md has not been updated
- build/docker/README.md have not been updated
- The cocoa implementation is separate from this implementation. The Cocoa
compiler/libraries exist for Obj-C, and Swift 1 & 2, whereas Swift 3+ operate
independently without Cocoa (as Swift 3 and up can run on Linux without Obj-C
runtime/libraries). That being said the old Swift/Cocoa compiler is
"gone/removed" and there is "only 1 Swift compiler" given the old Swift/Cocoa
compiler is integrated in this as a compiler flag
- Given this is a full rewrite it will not play nice with #1002, though
since that PR is related to the Swift/Cocoa compiler and that has been
integrated for backwards compatibility that PR can be rewritten to work with
this. My comments on that PR still stands, the style of "Namespacing" used
there by prefixing class names is a Cocoa convention that is improper in Swift,
This version does proper "namespacing" for Swift by putting generated files in
namespaced folders which should then be imported as separate modules, adhering
to Swift's module namespacing conventions, however for the Swiftv1+2/Cocoa side
its an acceptable pattern.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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
> Priority: Major
>
> 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
(v7.6.3#76005)
