MGLStyleLayer classes should conform to NSCopying

[1ec5]

We should make it easy for a developer to duplicate a style layer. Currently, this is a tedious process that requires hard-coding a method call for each property in the style specification. The most natural way to streamline copying would be to have the concrete subclasses of MGLStyleLayer conform to the NSCopying protocol.

Copying a style layer would not copy the raw pointer to the underlying mbgl object but would create a pending layer object and set all its layout and paint attributes without any developer intervention. We could implement copying support in mbgl, or we could implement it entirely at the SDK level. Either way, we can take advantage of the codegen script to avoid having to hard-code the list of properties ourselves. If we do implement the feature in mbgl, we could take advantage of the JSON serialization that would be added in #7563 to conform to NSSecureCoding at the same time.

I’d consider both NSCopying and NSSecureCoding compliance to be a GL JS parity feature, because it’s quite easy with GL JS to call getLayer() and use a common JavaScript library to clone the returned object or stringify the JSON object.

/cc @frederoni @jfirebaugh

[jfirebaugh]

The equivalent mbgl core method is Layer::Impl::copy. Note that this method requires id and sourceID parameters (ignore the ref parameter, that's going away soon). These parameters reflect the fact that id and sourceID are immutable once a layer is constructed. Can the NSCopying protocol faithfully reflect this as well?

[1ec5]

Yes, -[NSCopying copyWithZone:] and -[NSObject copy] are intended to make an exact functional duplicate of the object, so we’d implement -copyWithZone: by passing in self.identifier as the ID and self.sourceIdentifier as the source ID.

Note that this paradigm isn’t necessarily mutually exclusive with the idea that layers must have unique IDs. A developer might reasonably want to use -copy in the following way:

MGLSymbolStyleLayer *parkLayer = [[mainMapView.style layerWithIdentifier:@"parks"] copy];
[sideMapView.style addLayer:parkLayer];

Although that’s sort of awkward, since the SDK’s public interface halfheartedly pretends that a layer points to a source object as opposed to a source identifier. (MGLForegroundSource’s initializers require an MGLSource object, as a way to encourage the developer to create the layer after the source, but has only a sourceIdentifier property rather than a source property, so that we can avoid a backpointer to MGLMapView.)

In any event, the primary use case of duplicating a layer for use within the same map view would require a distinct identifier to be passed in. The typical way to express these semantics is with a “with” method: -[MGLStyleLayer styleLayerWithIdentifier:] (not to be confused with -initWithIdentifier:] or -[MGLStyle layerWithIdentifier:]), which we’d refine for Swift as withIdentifier(_:). So NSCopying would be orthogonal to satisfying this primary use case.

[frederoni]

Great idea.

Note that Studio just appends "copy" when duplicating a layer and subsequently starts incrementing. This feels natural when copying uniquely identified objects, copying files in Finder being the first that comes to mind. Although -[MGLStyleLayer styleLayerWithIdentifier:] is self-explanatory, we could implement both without much fuss.

[1ec5]

We could implement some sort of conflict avoidance inside the copy method, but that runs counter to the spirit of NSCopying, where the copy would be object-equal with the original object (assuming we override -isEqual:). As long as we provide a -styleLayerWithIdentifier: method, conflict avoidance within -copyWithZone: should be unnecessary.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.