@Daklu wrote:
"I would have thought that there was an easy route into basic LVOOP..."
Sure, that's a fairly easy way to get started for those already motivated to learn it for other reasons. But for many developers it doesn't provide a reason to learn LVOOP in the first place. What pain is being reduced for the CLA level developer by replacing clusters with classes? In many cases the answer is nothing--they already have coding conventions or dev practices in place to prevent the pain. For those people creating a class and providing accessors is pointless.
"Keeping bundle/unbundled private to a library is already a significant architectural advantage... but LVOOP is already an advantage used simply."
Personally I agree with you. I place a very high priority on managing dependencies and LVOOP helps me keep things organized, so it is a significant architectural advantage to me. However, the things that are important to me and that I value aren't necessarily the same things that are important to anyone else. Whether or not an arbitrary feature/practice is an advantage depends on what an individual or organization values.
I (as a lone programmer) found just the customized wires quite attractive all by itself. No more multiple indistinguishable cluster wires on a block diagram. But if I were to architecture code for a group of programmers, making bundle/unbundle private to the library and thus allowing a well-defined public API seems extreemly valuable. However, I never really much used things like "Action Engines" that might give some of the same advantages.
Now, dynamic dispatch is a whole new level of advantage, but one that does have a bit of a learning curve to it. I made simple uses of classes for over a year before I attempted any inheritance.
-- James
