Leaderboard

It may not be such a killer. The child objects have to have the parent (and grandparent) in memory anyway, so the penalty is the memory allocation of the default data for the parent's private data. I'd imagine that large data storage in a class would be in an array or other dynamically growable object (like a waveform or variant). So long as you don't set the default value of tge class private data to contain lots of data, the actualy overhead of storing e.g. empty arrays is not so large.

It's still broken in a yet-unannounced version after LV 2012, whose version number remains entirely unguessable. I filed CAR 382426. I have no workaround, since I don't know much about the compile process. I've noted in the CAR to post the workaround here if there is one.

Dynamic methods have dynamic dispatch input terminals for the object inputs and outputs of the owning class, meaning one can override those methods in child classes. One cannot override static accessors, but one can in-line these VIs, for instance, to optimize performance. It is possible to switch from one to the other by changing the property of the terminals on the connector pane, but I think it is far better to design appropriately in the first place. In the design approach we use, static accessors are the correct choice in about 98% of the situations we encounter. There are a few rare situations where we need to access data via an interface, so we do define a dynamic accessor method on the interface (but the interface's method never actually executes). My advice is to use a static accessor method unless you are really sure you need a dynamic accessor method. (This answer may depend a bit on one's design approach, though. I think what I have stated is a good rule of thumb, but there may be other sorts of designs that would have different answers.)