Review and tweak API using Swift guidelines
hassila opened this issue · comments
Creating this as a reminder:
It would probably make sense to make a final API cleanup iteration when 'all' functionality is in plac3 considering https://swift.org/documentation/api-design-guidelines/ for even nicer 'swiftyness'.
Probably should do this together with the move to Swift 3.0 - there are quite a few syntactical changes there...
I would be interested in getting some feedback on new API.
I would like to provide some - as mentioned in the other case, it will unfortunately be some calendar time before I will have proper time, but looking forward to it.
Starting having a look now, will make a pull requests with some polish for your consideration.
Should make a final review if there are any low hanging stuff that should be fixed, also in codegen.
One thing is probably in codegen for
public func toData(withConfig config : FBBuildConfig = FBBuildConfig()) throws -> Data {
---->
public func makeData(withConfig config : FBBuildConfig = FBBuildConfig()) throws -> Data {
for consistency.
@mzaks, what do you think of trying to introduce a new type for the vectors that conforms to the Collection protocol to give .count and subscripting access capability?
That is, try changing
public var addressEntriesCount : Int {
public func addressEntriesElement(atIndex index : Int) -> AddressEntry_Direct<T>?
to
public var addressEntries : FlatBuffersArray?
I have a vague memory we discussed it at some point but can't find it.
That would give natural array behaviour at the call site accessing the fields.
Yeah, we had it once and than I removed it when we started doing performance tests.
I just pushed a new version to https://github.com/mzaks/FlatBuffersSwiftPerformanceTest
Where decode_direct4_struct_with_vector uses a FBVector which is a Sequence implementation. It is however 5.5 times slower.
The _Direct readers a meant to best performance. If we manage to make decode_direct4_struct_with_vector comparable fast as decode_direct4_struct than I would be glad to add it to the main project.
Please have a look at mzaks/FlatBuffersSwiftPerformanceTest#1
I updated mzaks/FlatBuffersSwiftPerformanceTest#1 with latest results, looks good from a performance POV.
If you are ok with going forward, I'll adopt FlatBuffersSwift and make a PR for it.
@hassila no need to adopt it in the main project I will have to make the changes in code generator anyways. I will just do this improvement also in the same go. Anyways looks really good.
Ok, cool, thanks - quite happy it is possible to get the enumeration in a nice way without performance overhead.
Will regardless continue the review of the API in the context of this case, I think some arguments labels may need tweaking at least, hope to work on it tomorrow. But it is getting close now I think!
Yes, than I will still wait a bit with the changes to code generator.
Looks really much better now!
Ok, I think the final stab at it is in now:
The remaining thing is the move to vector accessor according to the mzaks/FlatBuffersSwiftPerformanceTest#1 style in the codegen.
I would be happy to close this one after the new codegen is in place now and perform any further polish in a separate issue in the future.
Cool, will do the code gen part tomorrow.