I can see where you are coming from, and I've thought about similar ideas. But ultimately, I think this fails for separation-of-concern reasons. Describing the part is different from describing how to make the part. The same part might be sent to 3D printing for a non-functional fit prototype, sent to a prototyping machine shop to make 5 or so units on basic CNC machines that require 3 set-ups to complete it, and after a few design iterations scaled to production on a multi-spindle Swiss-style lathe that drops finished parts into the basket all night long, lights-out. Those are wildly different programs and work flows.
Something like you propose might be an interesting thing to explore for creating CAM posts. The actual Gcode that your API would emit is going to vary quite a lot even within super-similar machines -- a 3+1 axis job targeting a machine with a FANUC controller is going to be pretty different from the same job targeting a machine with a Heidenhain controller.
> Describing the part is different from describing how to make the part. The same part might be sent to 3D printing for a non-functional fit prototype, sent to a prototyping machine shop to make 5 or so units on basic CNC machines that require 3 set-ups to complete it, and after a few design iterations scaled to production on a multi-spindle Swiss-style lathe that drops finished parts into the basket all night long, lights-out.
I think you might have a point here, but I'm going to push back on the idea that these three parts are the "same part" because they'll all have wildly different mechanical properties, dimensions, and dimensional consistency. They are not all necessarily interchangeable (although they could be, we'd have to integration-test them in an assembly to find out!).
My point is the "abstract part" isn't really a thing, and the real life characteristics of each concrete part are inextricable from the way it's made and what it's made of. I wonder if it would be helpful to force me, the designer, to think about it that way from the start?
3D printing is an odd case that tbh I hadn't really thought of. The things I make are all subtractively manufactured (except for welds which are addictive only in a degenerate sense), and I have no experience with 3D printing.
Too late to edit, but I've been foiled yet again by touchscreen phone autocorrect. While welding is certainly addictive (albeit in an entirely wholesome non-degenerate sense), what I meant above was additive.
Something like you propose might be an interesting thing to explore for creating CAM posts. The actual Gcode that your API would emit is going to vary quite a lot even within super-similar machines -- a 3+1 axis job targeting a machine with a FANUC controller is going to be pretty different from the same job targeting a machine with a Heidenhain controller.