The more I think about it, the less I sure I am that this strictly-immutable approach is really the way to deal with the problems it can create for patching scenarios. Mutability is a cornerstone of OOP, after all, and if vl wants to embrace that, it will run into problems with quite a lot of external libs.
There might be reasons (as in future features, that the devvvvs would not openly admit to dream about) that justify a design decision like like that, but we don’t know about them.
Granted that, I think a graphic way to make order of execution visible to the user (and maybe even manipulate it, eg by moving nodes closer or further apart, or prioritizing links) would help the issue a lot more than vls both enigmatic and dogmatic approach.
Otherwise people (me included) will take the first chance to hack something up as soon as a chance presents itself (which would be a weird thing, since passing around references in a managed environment is usually just - natural).
Hey devvvvs, remember, everything you know is wrong. Making the invisible workings visible might be something to consider.
that’s true what you say. we’re already thinking about this issue. the latest idea was to relax the rule and allow multiple connections for references but showing a warning when the order of execution is not clear. but no final decision yet, we have to see how much we can evaluate in compile time to help the user.