Exposing L1 Constructs in L2s

[moofish32]

Right now if you need to do something that an L2 does not support you are sort of out of luck. I end up reverting back to re-writing most of the L2 and then modifying what I need. With the lack of L2 support across the board this makes using an L2 very risky, because eventually you end up needing something not available.

One proposal that would alleviate this pain is to expose the L1 constructs from the L2s programmatically and warn the users that there is also some risk in modifying the L1s directly. However, during development this provides a mechanism by which a developer can continue. A simple example of what that could look like is here: master...moofish32:exposing-l1s.

Perhaps a less fundamental shift would be to use protected instead of private on all of these members and encourage developers to extend the L2 constructs when they don't meet your needs.

I realize we may all hate these two ideas, but this problem is occurring too frequently in my opinion. I hope this issue can drive out some proposals to reduce this pain and increase adoption.

[moofish32]

cc/ @rix0rrr @eladb @RomainMuller

[rix0rrr]

@eladb, maybe time for a quick implementation of findChild/overrideProperty?

[eladb]

Yes. This is on our mind (#606). We see this is “escape hatching” or “patching” the CFN resources and deliberately thought we didn’t want to make this “too easy” in order for those gaps to bubble up from the community. So we discussed potential programming models that will allow users to add property overrides to arbitrary resources within a scope.

Explicitly exposing the inner resources from L2 is akin to exposing private implementation details from a library. It’s effectively a “leak” in the abstraction, and becomes part of the API, which feels like a one-way door that I am not sure we want to take.

Having said that, the need is clear and will likely be a matter of life for a while. We are aware of major gaps in functionality across the framework, which will take time to fill in. And even then, we may always have some gaps.

Let me update #606 with some latest proposal for an API and we can discuss over there if it’s sufficient. I am not sure!

Closing as duplicate if that’s okay.