ianthetechie
commented
8 months ago Thanks for your involvement @hactar! It's great to have others using it!
But even for my limited use case I already see that there's going to be a LOT of boilerplate code to support all properties that the underlying MLNCircleStyleLayer supports - and any addition to MLNCircleStyleLayer will need an update to CircleStyleLayer...
Yes, by my count it's going to be dozens if not hundreds of properties per layer type to get to complete support :/
So my question is, is this the right approach? Wouldn't it be wiser to take this a step further and auto-generate these properties/modifiers from the definitions of MLNCircleStyleLayer etc themselves? Or is this something the current Swift cannot help us with? Maybe this is the goal already and I'm just stating the obvious, in which case, sorry - but wanted to contribute to any discussion 😊
Yes, a lot more auto-generation is definitely the long-term goal. Recently I haven't had as much headspace to devote to this, but here's a quick brain dump from me:
- I haven't done a large-scale property/modifier bridging effort yet precisely because I am not 100% sure the current approach is correct. In particular, I'm questioning whether the current macro attachment point is optimal or whether we can make things better another way.
- I actually TRIED to test a few alternate approaches (I had a peer macro in my working copy), but... a. At the time (a few months ago), Xcode / LLDB were broken and I couldn't actually debug the macros (which meant zero development, as there are basically no docs for macros at the moment; WWDC videos heavily feature LLDB cuz that's the only way to get a sense of what you're transforming haha) b. While MapLibre Native 6.0 is out for iOS, but it doesn't yet support macOS. This makes it incredibly difficult to build macros against due to the way that Xcode / SPM work at the moment, which led us to separate macros out into a separate project temporarily 😂 This is a drag on iterative development speed.
Jumping back to your direct question about auto-generation, at the moment, Swift macros don't give you compile-time type introspection of obj-c class hierarchies. They are just syntax transformers. So this is not presently possible. However, I have a very half-baked thought in the back of my head about writing an actual preprocessor that generates most of the Swift code in this project (I guess from the Obj-C), and uses macros for the heavy lifting, but I have not yet given too much thought to that.
Please feel free to brainstorm on this thread :) cc @Archdoog.
hactar
So in the spirit of this playground, I've started trying to add it to a real project to see how far this takes me.
I have created a CircleStyleLayer based on the SymbolStyleLayer - all is working well, and thanks to the Macros, adding the properties is less work then without them. But even for my limited use case I already see that there's going to be a LOT of boilerplate code to support all properties that the underlying MLNCircleStyleLayer supports - and any addition to MLNCircleStyleLayer will need an update to CircleStyleLayer...
So my question is, is this the right approach? Wouldn't it be wiser to take this a step further and auto-generate these properties/modifiers from the definitions of MLNCircleStyleLayer etc themselves? Or is this something the current Swift cannot help us with? Maybe this is the goal already and I'm just stating the obvious, in which case, sorry - but wanted to contribute to any discussion 😊