-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Conversation
@@ -186,7 +186,7 @@ - (void)parseFeaturesAddingCount:(NSUInteger)featuresCount | |||
|
|||
if ([features isKindOfClass:[NSDictionary class]]) | |||
{ | |||
NSMutableArray *annotations = [NSMutableArray array]; | |||
NSMutableArray <MBXAnnotation *> *annotations = [NSMutableArray 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.
Should this be <id <MBXAnnotation *>>
?
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.
When #1655 lands, it will actually be <MGLPointAnnotation *>
.
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.
No, MBXAnnotation
is a concrete implementation of MGLAnnotation
.
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.
Right, but that PR implements MGLPointAnnotation
as the SDK-provided concrete implementation of MGLAnnotation
; that's my point (heh). It mirrors MapKit. Devs will no longer have to create their own point annotation concrete implementation.
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.
Heh, sorry @incanus, that was in response to @friedbunny. (I was using GitHub’s mobile version, which doesn’t poll for updates.)
So Travis informs me that lightweight genetics are still off-limits. Xcode 7+ only. 😞 |
Actually, this isn’t blocked: since we only use collections to hold a small number of types, we can use conditionally-defined macros to indicate the same information. Such macros would fool Interface Builder’s parser, but none of the inspectables are collection-typed anyways. |
0d9f251 wraps lightweight generic usage in a conditionally-compiled macro. It all works beautifully, except that the signatures in appledoc-generated documentation now go from: @property (nonatomic) NSArray<NSString*> *styleClasses to: @property (nonatomic) MGL_COLLECTION ( NSArray , NSString **styleClasses Ouch. This issue is tracked upstream as tomaz/appledoc#373. |
OK, we’re all set now. I worked around tomaz/appledoc#373 by manually replacing all instances of |
Doesn't this make for a harder-to-read header file? |
Compared to the native Objective-C syntax, not really, in my opinion: mapView.styleURL = mapView.bundledStyleURLs[0] as! NSURL
mapView.removeAnnotation(mapView.annotations[0] as! MGLAnnotation)
// ^^^ obviously and: mapView.styleURL = mapView.bundledStyleURLs[0]
mapView.removeAnnotation(mapView.annotations[0]) And in both Objective-C and Swift, you get an error when you try to pass the wrong kind of objects into But given that lightweight generics are only bridged for NS[Mutable]Array, NS[Mutable]Set, and NS[Mutable]Dictionary, we could also do something more compact, like |
Well that confused GitHub. This was 91641ff by the way. |
Added lightweight generics annotations to collection-typed method and protocol signatures to streamline usage of these members in Swift. Lightweight generic type specifiers are wrapped in conditionally-compiled macros for compatibility with Xcode 6.x. Manually preprocess the NS_*_OF() macros in a temporary copy of each header before appledoc sees the headers. Also removed the --ignore flag because we no longer have a private headers folder under include/mbgl/ios/.
Added lightweight generics annotations to collection-typed method and protocol signatures to streamline usage of these members in Swift. I forgot to take care of this as part of #1578. Again, there are no stability implications, but two big benefits:
as!
casting in Swift code that uses Mapbox GL./cc @bleege @incanus @friedbunny