-
Notifications
You must be signed in to change notification settings - Fork 712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swiftify API #504
Swiftify API #504
Conversation
* used to store the output of its respective filter in the final | ||
* report dictionary. | ||
*/ | ||
+ (instancetype) filterWithFilters:(NSArray*) filters keys:(NSArray<NSString*>*) keys; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mind providing a type to array?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't. Here is a bad legacy design, where we can pass array of objects or array of arrays. From doc:
* @param filters An array of filters to apply. Each filter should conform to the
* KSCrashReportFilter protocol. If a filter is an NSArray, it will
* be wrapped in a pipeline filter.
@@ -56,15 +61,37 @@ | |||
* Each "filter" can be id<KSCrashReportFilter> or an NSArray | |||
* of filters (which gets wrapped in a pipeline filter). | |||
*/ | |||
+ (KSCrashReportFilterCombine*) filterWithFiltersAndKeys:(id) firstFilter, ... NS_REQUIRES_NIL_TERMINATION; | |||
+ (instancetype) filterWithFiltersAndKeys:(nullable id) firstFilter, ... NS_REQUIRES_NIL_TERMINATION; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we drop nil-termenated initialization? Not sure if it's used anywhere, but maybe it's just me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's visible for C, but not for Swift, that's why a implemented with NSArray
side-by-side.
KSCRF_DEFINE_CONSTANT(KSCrashField, BuildType, buildType, "build_type") | ||
|
||
KSCRF_DEFINE_CONSTANT(KSCrashField, MemoryFootprint, memoryFootprint, "memory_footprint") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also split KSCrashField
into smaller groups?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about it, but I didn't want to break the names.
…essary copy Co-authored-by: Nikolay Volosatov <code@bamx23.com>
Co-authored-by: Nikolay Volosatov <code@bamx23.com>
…ppropriate types Co-authored-by: Nikolay Volosatov <code@bamx23.com>
This PR introduces significant updates to the KSCrash library, focusing on enhancing compatibility with Swift, modernizing the Objective-C code, and improving maintainability. Below are the key changes made:
Major Changes:
instancetype
to ensure better compatibility and consistency across Swift and Objective-C. This change improves type safety and makes the codebase more modern and reliable.nullable
annotations to parameters and return types, where applicable, to clarify which values can benil
. This change is crucial for Swift interoperability, reducing potential runtime errors and improving code clarity.NS_ENUM
:NS_ENUM
to enhance type safety and facilitate smoother integration with Swift. This modification allows enums to be used more effectively in Swift, leveraging the language's type system for better safety and usability.@KSCrashField_XXX
string literal access withKSCrashField_XXX
constants to align with contemporary Objective-C practices. This change reduces the risk of errors associated with string literals and ensures a more maintainable codebase.NS_SWIFT_NAME
annotations to key methods and properties to provide more intuitive names when accessed from Swift. This improves the developer experience, making the API more natural and easier to use in Swift projects.