Style attribute enumerations redundantly include layer class names

[1ec5]

The style layer classes’ paint attributes are named somewhat redundantly, for instance -[MGLCircleStyleLayer circleOpacity]. Since there’s no possibility that, say, lineOpacity would ever exist on the same class, we should remove the first word from this property and any property like it. It’s totally fine if, say, width means something slightly different on circle and line style layers, since the meaning on each is consistent with developer expectations.

Putting on the v3.4.0 milestone because we won’t be able to change this later without breaking backwards compatibility.

/cc @frederoni @incanus

[1ec5]

This would also simplify enum names. For example, MGLLineStyleLayerLineTranslateAnchorMap would become MGLLineStyleLayerTranslateAnchorMap. We could go a little further, shortening it to MGLLineTranslateAnchorMap.

[incanus]

Since there’s no possibility that, say, lineOpacity would ever exist on the same class

Is this true? For fills, we've long talked about allowing for variable-width outline (mapbox/mapbox-gl-style-spec#223, #1737) and I could see possibly getting a circle outline someday.

[1ec5]

If so, I think the style specification would call the property something else, like line-stroke-opacity, so there would be no collision. As it is, the only properties that aren’t prefixed pro forma with the layer type are the layout properties that are shared among the types.

[1ec5]

@lucaswoj points out that many symbol properties aren’t prefixed with symbol- but are instead prefixed with text- or icon-. Could we use a heuristic like:

• If the first part of the property name matches the layer type, omit it.
• Otherwise, use the property name verbatim.

That would allow us to differentiate where needed but avoid redundancy in most of the API. However, it would assume that the circle layer type can’t have a line-color property; it’d have to be called circle-line-color instead. I think that’s a reasonable constraint to put on the style specification.

Even if we can’t shorten the property names, I still think it’d be desirable to shorten the unwieldy enum values.

[jfirebaugh]

I suggest you just accept the redundancy in property names. That's the most predictable and future-proof solution.

Shortening the enum values seems fine. Those aren't prefixed in the style spec to begin with.

[1ec5]

Alright, not the end of the world. Retitled to reflect the focus on enumeration names and values instead.