control-drag object (SQL statement) allow last select hold

[EngrStudent]

I'm making an SQL statement using the SQL library, but I'm sure this is a LabVIEW and not an SQLite idea.

I have this when I drag down on the "bind parameters".

Each time the drag downwards it goes to a different "bind". 

I want to connect a big stack of integers.

I wish that I could control-drag and get whatever the last one was to stay the same.

[Intaris]

I can chime in with my 2c.

Given the static nature of table definitions in SQL it is soothing (mentally and spiritually) to also have a static indexing of data into columns.

So in the absence of fixed length arrays on windows...... a large expanded property node is a practical alternative even if its not technically what a property node is supposed to be. Just my view, may be completely stupid.

[AristosQueue (NI)]

@drjdpowell: This sort of syntax abuse is *exactly* why I debated the appropriateness of adding support for the property node to LabVIEW classes. A block diagram must serve two masters: the programmer who writes it and the programmer who reads it. This kind of abuse is kind to the programmer who writes at the expense of the one who reads. Properties with side-effects are too easily over-looked when refactoring or simply trying to debug. It is a form of operator overloading that bends against the common interpretation of the operator.

In other words, I understand why you did it. You have a different value proposition for your APIs than I have for mine, and while I understand that reversal, I think this is a case of serving a small case (one API) and betraying a larger case (language readability generally).

> LVOOP “Properties” are implemented as subVIs, and

> thus aren’t strictly limited to property-like behavior. 

They are subVIs so that you can do property validation, coercion, and messaging. Abusing that ability to have side effects is just as wrong as any number of other things that you *can* do in software but shouldn't in good code.

The operator overloading in C++ let's you write functions to replace things like "+". An overload for the "+" does not have to do anything remotely like addition, even when handed integers. But when I see "numeric array + numeric array" and then after an hour of debugging discover that it has been overloaded to do concatenation of the two arrays, I'm not happy. This abuse of the property syntax is in the same category.

[drjdpowell]

To be Devil’s advocate, how useful is this “Property” mental model?   Objects encapsulate data behind a set of methods, but this mental model promotes an image of an “object" as a loose collection of weakly-related values that have no meaningful clustering.  Aren’t subVI’s, with appropriate icons for readability, much better ways of guiding the API User in how to set properties?

And it appears to me that the “Property Node” structure doesn’t exist to allow properties; it exists to make it easier to call lots of “Write” properties together than using a long string of subVIs (with “Read” properties it promotes serialization for no obvious reason, and loses the ability to use the lack of an object output to indicate that lack of changing the object).  But my SQL Parameters and Column values benefit from that too.  In fact, they make even better use of the syntax, as they naturally come in ordered lists, matching the ordered list of “properties” in the node.

[drjdpowell]

I guess what I’m saying is that you are suggesting we protect this syntax for use with “Properties”, but I’m suggesting it is more useful as a way to chain a lot of simple method calls.

[AristosQueue (NI)]

> Aren’t subVI’s, with appropriate icons for readability, much better ways of guiding

> the API User in how to set properties?

I did say I had hesitations about enabling the property syntax. 🙂

> I guess what I’m saying is that you are suggesting we protect this syntax for use

> with “Properties”, but I’m suggesting it is more useful as a way to chain a lot of

> simple method calls.

Chaining a lot of method calls is problematic because of all the parameters. That was *explicitly* rejected as a design choice early in LabVIEW. I have never revisited that design choice myself, but my instincts are that it would be cumbersome.

Moreover, I think the syntax of a setter/getter is useful -- still implemented as a method with range checking, validation, etc -- as a unique type of method, and that the choice to use that syntax should indicate a particular usage pattern. There are plenty of good classes that do have simple attributes for their state data, and providing a syntax that clearly indicates that hygenic nature is a useful thing. It ceases to be useful at all when respected API designers abuse it, because then we all have to start questioning what we're seeing on every property write/read. And at that point, yes, icons for method calls are absolutely better choices.

[AristosQueue (NI)]

>  with “Read” properties it promotes serialization for no obvious reason

Error chaining. If we got rid of the error terminals (as I continue to lobby for us to do), the compiler could compile in reads in any order it wanted. Of course, then people who abuse the syntax would complain... 😉

You claim to make better use of the syntax. That may be true, but the convention isn't yours alone to contravene. It isn't mine alone to contravene either. There are established expectations among our users, and designing an API that goes against those expectations undermines readability for the whole system. Therein lies the problem with this -- or with operator overloading, or any other creative syntax use. 🙂

[drjdpowell]

The answer would be to provide a feature that allows me to solve my problem without “Property Nodes” for non-properties.

[AristosQueue (NI)]

Or the answer is to convince you that you don't have a problem and just use the software as intended.

It works for some customer problems, and it is less work for me, so I'll start there. 🙂

[Dmitry]

When I see a class with multiple accessor methods I tend to think - leaky abstraction. And make a note to review/refactor that class hierarchy layering ... Which makes me think the entire LVOOP Class Property Node construct should not exist in the first place, making this conversation irrelevant ...

This conversation (including my comment) also reminds me of the 'rhinoceros' scene in a Woody Allen movie (full scene version here😞

"Man Ray: A man in love with a woman from a different era. I see a photograph!

Luis Buñuel: I see a film!
Gil: I see insurmountable problem!
Salvador Dalí: I see rhinoceros!" 

[AristosQueue (NI)]

Dmitry: While I agree with you that a high accessor count is a code smell, in practice, the vast majority of classes have a fair number of simple property accessors, and lowering that is an expense way too high to pay in most development projects. It is further complicated by hardware engineers and their users that *insist* that a class with 400 properties is highly preferable to any other architecture *because* it leaks the abstraction. The lowest level programmers live in terror of abstraction even as they enjoy having classes to organize their low level domains. There are so many use cases for properties, from good cases to necessity-driven bad cases, that the property syntax isn't going anywhere.