Fluent Interfaces with Method Chaining for Objects (especially .NET!)

[JackDunaway]

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

See the first comment for footnotes...

[JackDunaway]

>> This fits well with your suggested LabVIEW functionality of "subsequent methods must always act on the parent object." However the general method chaining ability in .NET is not restricted to this definition... In the Linq statement "list.OfType<Person>().Select(p => p.FirstName).Distinct().OrderBy(n => n).Take(10)" each method is invoked on a different object, many of which have different types.

That's a good point that I agree with: I guess we're not requesting that LabVIEW fully implement chaining as it works in traditional .NET languages - e.g., defining a new syntax for heterogeneous chaining would be klunky.

>> Your suggestion gives LabVIEW a better syntax for #1 [classes not designed for chaining] and #2 [fluent classes (chaining on same object)]

The fact that LabVIEW can do #1 is actually very cool. Consider a class containing methods that lend themselves well to chaining, yet the class developer used "return void;" rather than "return this;". This could be considered a deficiency in the design of the class interface. Yet LabVIEW natively makes up for this deficiency! (Arguably, #1 is even the better scenario than #2 in LabVIEW -- notice that the output object references from methods "WithFilePath", "WithKey" and "WithBucketName" are unwired and unused. This is the best indication that "method chaining" in LabVIEW does not have the same definition as "method chaining" in a traditional .NET language, and therefore might have a better name.) I would agree with you that #3 on your list probably does not lend itself well to LabVIEW syntax (or rather, there's not a sufficiently cleaner method than the current behavior).

Finally, definitions and terminology aside, what do you think about the proposed syntax in the original idea? Are there any problems, or inconsistencies? And you say you've debated internally a lot; what are both sides saying?

[GregR]

Internally we have always considered the #3 case as more important and we have never come up with a representation we liked. So the concept as a whole has been a little out of favor.

More recently there has actually been more talk about sticking with a one method per node model like subVIs but creating a "no names" view that is actually useful. Part of what makes the invoke node so big is showing the names for all the parameters. What if the smallest view just showed the method name (and possibly the class name) in a smaller box with terminals spaced around it more like a normal node? Since most .NET classes use camel case, we can use those cues to do intelligent line wrapping. This would probably still be shorter than the current nodes but we would use some of the vertical space to allow multiple lines of text and reduce the node width.

The other concept that keeps coming up is actually using text. Turns out .NET programming is designed around textual languages. Even from LabVIEW perhaps text is a good way to express .NET interaction. So what if the formula node or something like it supported calling .NET objects. This could mix properties and methods. It would allow chaining or using properties or methods as parameters to other methods or all the other crazy ways of combining code. For a system like this how much should be visible from the diagram? Should it be like the formula box where all the text can be directly visible? Should it default to some smaller diagram presence?

Either of those sound promising?

[JackDunaway]

>> Internally we have always considered the #3 case as more important

This is surprising! Why is #3 is the most important case? I would consider that the least important consideration, because it's the least intuitive. I can understand how #3 maps well to the traditional .NET language chaining concepts -- but I don't see those concepts mapping well to LabVIEW syntax anyway, and it just doesn't feel too appealing. I've just never thought to myself "Man, I wish I could have an invoke node stacked with many methods all acting on different object types". Just feels kinda funny.

>> More recently there has actually been more talk about sticking with a one method per node model like subVIs but creating a "no names" view that is actually useful

I'm skeptical. The node as it exists already has essentially the perfect information density - any smaller obfuscates, any bigger wastes pixels. Keeping the full names shown helps by self-documenting, especially when programming side-by-side with MSDN docs. Would have to see a mockup to say if it's a good idea or not - do you have any artwork?

>> The other concept that keeps coming up is actually using text... what if the formula node or something like it supported calling .NET objects

That's a good conversation - I have wished for this before! (Like earlier today, really wishing LabVIEW would allow me to wire something meaningful into an AsyncCallback parameter)

>> Either of those sound promising?

To implement the spirit of this idea, honestly, no. 🙂 The "iconification" sounds iffy, and although a new code node would be cool, it's a bit too abstracted from this suggested simple and effective syntax optimization that's immediately useful and elegant and discoverable "as if it always existed". Again, are there any problems with the suggested implementation? Is it too specific, or kindof a hacky language shortcut, or does it violate some syntax rules or concepts? 

Spoiler

A bit off topic, but that comic has one of my favorite hidden tips: "I find that when someone's taking time to do something right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they're a master artisan of great foresight."

And I'll say, thanks for the conversation! It's been helpful to better understand method invocation concepts in .NET. I'll come out of this conversation more learned, and you'll come out saying "man, let's build us some stackable Invoke Nodes!" 

[GregR]

I was trying to avoid showing off my mad Paint skills, but it might look something like below. One key to this is a related change to show the names of all terminals when showing the wiring guides (even for wired terminals). This means that the diagram always shows the method name and the parameter names are easily visible by hovering over the node. The terminals would have a repeatable layout so I think you would quickly learn to recognize the layout of methods you commonly use. We would pick a target width to height ratio so the node would vary in both dimensions depending on its name.

 

>> Why is #3 is the most important case?

I'm going to go back to my categorization approach. Let's divide all people who use .NET in LabVIEW into 3 groups:

1. those who only use .NET from LabVIEW
2. those who are familiar with both LabVIEW and textual .NET programming
3. those who commonly use textual .NET programming and must write LabVIEW code to interface to it

Groups 2 and 3 are accustomed to being able to chain any combination of methods and properties as long as each returns some sort of object. When LabVIEW doesn't provide that flexibility it feels worse because they can make that direct comparison to textual programming. Of course I and many of my NI colleagues fit into group 2.

[JackDunaway]

Your paint skills aren't that bad!

When I see that mockup, let me attempt to create a similar mockup in C#, showing methods chained together

var request = new TransferUtilityDownloadRequest()

.WithFilePath(...)

.WithKey(...)

.WithBucketName(...); //Hover mouse over ellipses to see expanded text

This shows that hiding code in the IDE just for the sake of reducing footprint is probably a bad idea. It's hard to interact with, hard to read, hard to share on a forum...

And here's an example of a close approximation to this mockup that's already available with today's syntax (I recommend against this "No Names" style):

>> Of course I and many of my NI colleagues fit into group 2 [those who are familiar with both LabVIEW and textual .NET programming]

I fall squarely into group 1 [those who only use .NET from LabVIEW]. As a Group 1 Spokesperson (and as someone who loves to dork out on obsessing over LabVIEW syntax), I would like LabVIEW to embrace its native ability to chain together methods that act on a common parent object. Here, to my understanding, LabVIEW is even better than traditional .NET languages, yet it's not as syntactically capable of arbitrary heterogeneous chaining, so let's just embrace what it's good at!

If this idea is rejected solely on the basis of not being able to support heterogeneous chaining and at the expense of a quite common, intuitive operation simplified, I speak for collectively for Group 1 that we would be sad

[GregSands]

Jack Dunaway wrote:

---

And here's an example of a close approximation to this mockup that's already available with today's syntax (I recommend against this "No Names" style):

---

In this case at least, the "No Names" style seems to work just fine.  It's pretty obvious what each terminal is, and a quick hover will confirm anything that's ambiguous - I often need to do that for "ordinary" VIs and functions anyway!  But I can follow this example extremely easily.

[JackDunaway]

---

@GregSands wrote:

In this case at least, the "No Names" style seems to work just fine

---

To be fair, you're right that this works pretty well (while creating this mockup, I was thinking "man, I wish this looked way worse than it does!"). This simple example could easily become more complex with more inputs to the methods, and may not look nice anymore. And even still, this syntax is not as elegant as the proposed syntax!

[X.]

Although I am rarely if ever using any of these .NET functions, it seems to me that this is another case where LabVIEW might be better off using a specific "text-mode" node as in "Formula Node" or "Mathscript Node". Not mentioning that this is pretty platform-specific as it goes.