And how would you implement "Goto definition?" For a line segment that you didn't directly create and is an incidental artifact of a sequence of CSG operations.
The line segment is not "defined" like a variable. There is no line in the code that gives you a declaration. It is a build artifact.
With a table that stores the source locator of the operation that generated the visualization and a program to query this table.
A rendering is not a build artifact except in the purest sense, it's just a different view into the source code. If you want to transition back to code you store the information required for it, it's not terribly difficult.
Another analogous feature is setting a breakpoint. They're not exactly equivalent, but depending on how the visualization is treated by the programming environment it covers what you're talking about.
Not really, vtables are a way to implement dynamic dispatch. A "table" is just a key/value store (in a vtable, the key is a function/method identifier and the value is the function itself).
In this case the key is the geometry and the value is the code that created it. But the real trick is to make sure the opposite is true, so you can go from code -> visualization and visualization -> code without a ton of difficulty.
Vtables are the digital analogue of signed distance fields. That is the trick. Rust gets this right. It is why most rust developers use text editors instead of UML diagrams. We can do the same with CAD. Instead of using a transformer network put the whole geometric inversion in level 1 cache and dispatch through the vtable. The borrow checker does the rest for you. No need to use the mouse anymore. The geometry inversions are now just a keyboard press away.
Rust doesn't use vtables by and large - like I said it's a technique for implementing dynamic dispatch (call a function with a different implementation based on the type of one argument, aka single dispatch). Notably, Rust does not rely on it for most cases (Rust uses type classes aka traits which are monomorphized - unless you explicitly use the `dyn` keyword to use a vtable implementation that incurs a slight performance penalty).
Not sure what they have to do with signed distance fields. It's just an implementation detail for single dispatch. What's the analog?
Signed distance fields are like vtables. You can invert the cross product and you can introspect information that is otherwise not observable. That is you call a method in user space and it is dispatched to the origin. It is a monad or more specifically an applicative over the geometric inversion. Instead of selecting the segment with the mouse you perform a bind over the generative original data. Thus the projection in the limit provides the functor towards the flat space in which exists the segment that requires selection. You are right. Vtables are not enough but with the borrow checking rust provides you no longer need to track the ownership of the space vectors of the transitive solution. It's pretty complex stuff as a library writer to formulate but once encoded it is not much harder to use than a CSS selector. If you spend a few minutes thinking about it anybody could code it up I'm sure.
The line segment is not "defined" like a variable. There is no line in the code that gives you a declaration. It is a build artifact.