[Wish] Extend the Point and Vector structs with arithmetic operators

[dimven]

Not really a bug report, more of a wish item. It would be great if we could perform arithmetic operations with points and vectors, similar to Revit's XYZ class:

where a new struct instance is generated after every operation.

It would be even better if that could be integrated with the existing DS syntax. For example:

a = Point.ByCoordinates(1,2,3); b = Point.ByCoordinates(1,2,3); c = a + b; => Point ( 2, 4, 6)

or

v1 = Vector.ByCoordinates(5,0,0); v2 =v1 * 10; => Vector (50, 0, 0); //yes we have a scale method for vectors, but it would be nice to use operators instead

[tatlin]

@keyu @ptrbyr

[mostaphaRoudsari]

YES and also add item selections to points and vectors.

point[0]  # returns point.X
point[1]  # returns point.Y
point[2]  # returns point.Z

[tatlin]

@pboyer

[aparajit-pratap]

It would be nice to support this in DS and the FFI so that when operators like + are compiled to .add methods they are routed to an FFI function endpoint that ends up invoking the operator overloaded method in the ZT class. This way any C# class can be used with its own custom overloaded operators - @sharadkjaiswal @ke-yu

[ke-yu]

To me DS is more like a lower level DSL than a general programming language. Though C# assembly could be imported and be invoked from DS with the support of DS implementation (Dynamo DS VM) in Dynamo, DS itself is not designed to work only with C# and work only in .net environment. It is language agnostic. Its major purpose is to "glue" computations -- which could be C# assemblies / RPC services / RESET APIs-- in a DAG (directed acyclic graph) so that its implementation could execute them.

So, a feature in DS should be general enough so that it works with different computation contexts, or it doesn't depend on some context. For operator overload, DS has no idea how to execute + until Dynamo DS VM hands it over to .net runtime. So I'd prefer to do these things by zero touch libraries directly.

[sharadkjaiswal]

I think operator overloading including index operator needs to be supported by design script VM. Then FFI layer can do the plumbing if it's implemented in zero touch library.

[pboyer]

So, I really like this proposal, @dimven. It seems natural.

For us, @aparajit-pratap @ke-yu @sharadkjaiswal, I think we really need to establish a framework for thinking about adding features to the language. What questions can we ask before saying "yes"? This would get us aligned about the future of the language.

For example, in the Go language, there is a strong effort to keep the language features "orthogonal". This is a fancy way of saying they interact in well-considered ways. The result of this is the language is very small and easy to pick up - a big part of it's success is it's clarity.

Historically, the bar for inclusion of a language feature in DS, as far as I can tell, is whether it "supports exploration" or similar rhetoric. While I enjoy this notion of a user "exploring" with great freedom the landscape of design possibilities, I don't think it is a sufficiently objective framework for answering these kinds of questions. :)

I've made a few stabs towards a framework for thinking about language features. One example is "Any textual language feature should have a direct visual equivalent of the same power." It's worth mentioning that there are several features in our system that do not really have this property:

1. Lacing - no textual equivalent - it's basically just a special case of replication guides
2. Currying - there's a function to do it, but it's difficult to use. No user would ever really use it, nor would I recommend them to.
3. Dictionary index setting - I don't believe there's a node for it and there's no visual way to specify order of evaluation in the graph
4. Imperative block variable capture - there's no imperative block node, nor can you explicitly specify how you capture node values as one can easily do with Python nodes
5. Custom nodes - custom node names make them nearly impossible to reference inside of a code block

I'm making this statement just to clarify that you can think of our language cleanup efforts through this simple, objective lens. Maybe you think the visual-textual bijection approach is flawed. As with most rules, it's bound to have corner cases where it doesn't work, but I think it's a good starting point.

While I'm excited about supporting something like operator overloads, I think we need to balance new features with a lot of these very important language cleanup efforts that will make the system far more usable.