[
https://issues.apache.org/jira/browse/THRIFT-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358479#comment-15358479
]
Chris Simpson commented on THRIFT-3773:
---------------------------------------
I've started working on this and have made a fair amount of progress so far so
I'll post for others to comment on and give input,
https://github.com/apocolipse/thrift
A couple of notes per the design goals:
- This will not be compatible with the Cocoa-Swift compiler, a new Swift
compiler is being rewritten, and being written towards Swift 3.0 API Design
guidelines.
- Run on Linux was the first goal
- Pure Swift library clean of any Objective-C or even Cocoa paradigms
- Only dependent on Foundation (The Swift variant coming with Swift 3.0)
- Interface will mostly be the same, but will notably be "Swift First" in
design, so the library likely wont be directly compatible with Cocoa generated
code and vise versa.
- Objective-C library out of scope for this
- Swift packaging has been considered but may also be out of scope, SPM is
still in its infancy and not very flexible yet, and other alternatives are "3rd
party" enough to ignore.
I've mostly finished the Library so far, but its still a WIP. I'm working
through the code generator.
A couple of notes on what I changed and why it wont be so compatible with the
Cocoa generator/library
- Completely redone error model. Errors are all very "Swifty", still giving
appropriate underlying error codes and messages but with an interface for
throwing and reading done in a clean manner (Throwing most errors is just 1
line of code!)
- Abstracting much of the generated code to the library via protocol
extensions. It struck me as odd that TStruct.write() was being repeatedly
generated for every type of struct, when it could be abstracted at the protocol
level with reflection. Similarly TEnum's are all RawRepresentable Int32 Enum's
that can also be similarly abstracted in the library. Replacing all generated
TStruct.write() generation is a single lookup dictionary for field ID's
generated for each struct (Which also doubles as a quick reference to field
ID's for dev's looking at the generated code)
- Default Values! Default values weren't handled at all in the Cocoa (Obj-C Or
Swift) library/generators. Additionally, non-optional properties on struct's
were initialized with an empty version of their type! Not only confusing (What
is the value of `let num = Int32()` ?) but requires that all TSerializable
structs and enums have init()'s as well, making for a headache when asking
"whats the default value then?". Removing `init()` requirements, and properly
implementing non-optional values, as well as including default values for both
struct members and service methods is a primary goal here (still havent nailed
out how to handle service methods as protocol declarations can't have default
values in Swift, however it can be implemented in the generated Clients, or as
a protocol extension, and/or as a default value for the args_struct's member)
- Value Typed transports and Swift 3.0 API design. Foundation in Swift 3.0
gives us a value typed Data, so all the transports have been rewritten to take
advantage of Data as a value type. This results in cleaner code as less Unsafe
pointers are being thrown around everywhere. In addition, I've updated much of
the interfaces to be more conforming to the Swift 3.0 API Guidelines, this
means things like all TProtocol methods are named `func read() -> String`
rather than `func readString() -> String` (per API Guidelines, remove redundant
words!) This can be changed if the Thrift community feels TProtocol methods at
the least need to look the same everywhere, however I felt at the time this was
a good fit. Similar changes to TProcessor, TTransport, Factories, etc. were
made to streamline naming (no extra words, don't name fields as their type, and
so on)
Stretch goal (and somewhat implemented) - Documentation! Thrift supports
docstrings in IDL files for everything, transposing them to Swift would be a
great tool when using with Xcode, option+click to look up docstrings!
Again, all a WIP and would love some feedback and input, The library is 95%
complete (compiles fine, crude tests were successful) and the code generator is
about 50% complete (generated code somewhat compiles)
> 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
>
> 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.4#6332)
