I think it would be nice if , when creating a form using a layout, the form inherits that layout , similar to how forms generate and inherits their templates.
This would make behavior like raising an event on the form , described here : Layout Close Button , would be smooth.
They considered that approach, but it creates its own problems.
For example, suppose that both the Layout and the descendant Form each define member function show, to respond to the corresponding event. With inheritance, there is now a conflict:
show, or the descendant’s show?Conflicts and complications like these tend to make the situation harder to teach, understand, code for, and debug. They are inevitable with inheritance – but not with containment.
With containment, the layout is a separate object, and can have its own event-handlers, for transparent self-management, with no interference from the Form that uses the Layout.
That said, I’m sure that our Anvil friends will find ways to make the integration easier, wherever there are concerns that span both objects.
I see. I assumed it would follow general inheritance overriding, but if there is other issues like described above, I accept that!
Thank you.
Caution: high-level abstraction ahead. I could be over-generalizing.
As I see it, the issues center around division and sharing of responsibilities (and data) between the two levels of objects.
Which responsibilities belong with which object? Which are shared? It really depends on the specific case one has in mind.
Containment and Inheritance are both tradeoffs.
Inheritance gives you very strong coupling, which can help with some circumstances, but can also box you in. It tends to be useful when the descendant is a subtype of the parent: an “is-a-kind-of” relationship.
Containment generally gives you better isolation, and supports a wider variety of uses. It tends to be useful when the form “has a” Layout.
“is-a” Layout vs. “has-a” Layout. Which one fits best? It really depends on the situation.
In the C++ world, Inheritance is often treated as a last resort, due to the very tight coupling (set of constraints) it creates. Containment is frequently recommended as the preferred alternative.
In the worst case, where you want “is-a” behavior, but you’re stuck with a “has-a” implementation, at least the container’s developer has the option to forward any relevant requests to the contained object.
The reverse situation, where you’ve got an “is-a” implementation, but you want “has-a” behavior, seems to me to be rather difficult.
One of Anvil’s goals is to make things work simply enough, that we can reason about them. At least, reason well enough to have a good chance of making things work. In this case, containment seems (to me) to do that much better than inheritance does.
I think that having the layout have an attribute that links to the form that’s consuming it would be good – just like the one I constructed in the linked question. I think it’s realistic that the controls in layouts will want to modify various things in the consuming form and have access to them as well. It would be nice to not have to construct that consumer attribute myself everytime I need access to the consuming form, haha.
I agree completely. However, given that we have DataGrids, and other “consumers” that are not always immediate parents, nor are they always the current top-level form, it’s hard for me to see how you could guarantee that the “consumer” you get would be the one you need or want.
In those cases there are different containers and whatnot that make the parentage difficult. With layouts though, there always the one form that is using the layout and consuming it. It could get more complicated if a layout uses another layout, but that’s the same level of complexity as the parent attribute and I use that all the time and would not want it removed.
Agreed. I’m sure that parent’s not going away any time soon, anyway. Too much code depends on it.
I appreciate the back-and-forth guys!
I see no resolution except for anvil to create a new hybrid layout form that creates my application for me 
(Here comes devin ai).
In all seriousness, I definitely see complexity of the decision, now. Maybe there can be a middle ground discovered by anvil or they can just close this request as “we decided to not go down that route”. I think either is acceptable.