forking off from the `fmt` / `fix` thread: we obvi...
# development
forking off from the
thread: we obviously haven’t been focused on plugin stability recently, but we have been adding items to as a grab bag of things that we might want to resolve before stabilization.
some of them are very much “wish list” items rather than actual necessities. but there are some issues that definitely qualify as blockers in my mind: in particular, since `@union`s are too limited right now.
and, having finished reading through that thread, i think that i was assuming it was more about the plugin API than it actually is: user API deprecations are another story
i’ve aded an example to #12934, which might spark some ideas for API changes:
Copy code
class Field:
    async def compute_default_value() -> Any:

class JvmResolveField:
    async def compute_default_value() -> Any:
        jvm = await Get(JvmSubsystem, ..)
        return jvm.default_resolve
…it could allow for pretty significant improvements to plugin APIs.
Finally someone using
on a method 😈
Don't forget though the `Get`s are collected using static type lookup though
yea, see the other (recent) comments on that ticket. this would require some sort of syntax at callsites to connect the list of
I semi-dream of a world where any field is defaultable with options. Really completes the story for fields/options/`__defaults__` IMO. This would get us closer 🙂
I don't completely grok the issue link, but I'm sure I will when it comes closer to fruition