question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Discussion: updates and breaking changes to the API(s)

See original GitHub issue

Please read this, even if it is a bit lengthy, as it contains information about future BREAKING CHANGES to OpenJSCAD, and the reasons behind it.

The current sitation:

  • currently there are two APIs that you can use for modeling :
    • the functional, somewhat openscad-like API : ie sphere(), circle() , rotate_extrude() , translate([0,1,20], shape1), cube({round: true}) etc
    • the (somewhat) ‘object oriented’ CSG.xxx api : ie CSG.sphere(), CSG.circle(), CSG.roundedCube() etc
  • both apis are
    • semi overlapping : CSG.sphere => sphere , etc
    • the functional api has more features, for example most extrusions are only in the functional api,
    • and often incoherent: not all extrusion parameters have the same ordering etc, some CSG.xxx api parts are attached to objects (Polygon3D.solidFromSlices()etc) which make them harder to use

Issues:

  • it is harder to know which one to use and when : instead of having one clear API we end up with two half baked ones
  • it doubles the mental load : ie you should not be using NEW with a lot of the functions , yet a lot of people (me included haha) use them in an wrong way : ie new CSG.cube() is wrong since it is not a constructor, just a function (so …the same as the functional API, just less clear)
  • the CSG.XXX api make it much more complicated to add new features and expand the capabilities of openjscad
  • the CSG.xxx api muddies the difference between ‘internal’ code (that should not be used directly) and code targeted at end users (all of us 😃
  • clarity vs concision : a part of the current APIs sometimes relies on argument positions which is a lot less clear than passing configuration objects ie cube({size: 10, rounded: true}) is a lot more explicit then cube(10, true) , even if a bit more verbose

What we are doing (as in the core maintainers)

  • we have been doing a LOT of restructure cleanup and documentation work inside both csg.js and the badly named scad-api
    • to clearly seperate the ‘core’ features from the more user facing ‘api’
    • to make it clear what the actual set of features at our disposal is
    • preparing to merge the two APIs & their repos : to have a single , simple logical place for all API related things
  • it has also become clear in the process that we will HAVE TO MAKE SOME BREAKING CHANGES
  • we will be doing the best we can to make the transition as ‘soft’ as possible, by first soft-deprecating some parts of the api (you will get a warning in the console that you should switch to specific replacements in the API) while introducing new ones

Parts of the code that will change (a lot more will be added ):

  • rectangular_extrude => flip parameter ordering to match other extrusions
  • rotate() / translate() /scale() (functional variants): will likely return arrays if provided with arrays : ie no more explicit union of shapes when passing arrays!!
  • solidFromSlices() : remove from polygon3 prototype, and make it a “root level” function like rotate() / scale() etc ie solidFromSlices(polygon, options)
  • lieFlat(), overCutInsideCorners() same as the above ie overCutInsideCorners(cag, 2)
  • area(), volume() etc same as the above ie const areaOfMyShape = area(areaOfMyShape)
  • we are still brainstorming it , but some of the Math utilities will be simplified and simple arrays will be favored for things like vectors (this is still work in progress)
  • some of the shape creation APIs might change a bit (work in progress)

Consequences:

  • some of the current scripts that you have written MIGHT break at some point in the future
  • the scad-api will be deprecated and integrated into csg.js in one shape or another
  • we will be strongly encouraging the functional api over the one using the object prototypes
    • the CSG.xxx will thus be the most strongly reduced part
    • we will make sure that the functional API becomes cleaner and clearer
  • we will NOT be clinging to either the Openscad or the original CSG.js heritage for some of the functions, and always favor clarity
  • we will also NOT break things often 😃 As the aim is not to make things worse for everybody , but to make them more pleasant to use in the long run and more forward facing
  • we will NOT be breaking things overnight, and the new api and documentation will be ready BEFORE we deprecate anything

Discussion :

  • we are of course open to discussing the details of these changes, so if you have questions/ and/or feedback it is very welcome
  • please keep the discussion focused : this is NOT about adding new features, it is about how to use the current set of features.

cc @z3dev 😃

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:18 (8 by maintainers)

github_iconTop GitHub Comments

1reaction
kaosat-devcommented, Jan 16, 2018

Thanks @danmarshall ! This has been a while , but things have been progressing well :

  • the merge of csg.js & scad-api is almost done
  • the internal split between core & api features in csg.js is done
    • this involved a lot of internal cleanups, and aliasing
  • the two above made the internal & api mess even clearer !
    • the whole prototype chain, and how some classes get added methods to their prototypes, but outside their scope , almost as an after-though is horrid
    • there is a ton of duplicate / non sensical code that will need to be cleaned up in the future

A few additions to the list of things that will be removed in the near future

  • the ‘openjscad.log’ utiliy (it was a weird one, totally useless)
  • the debug.echo utility : the same
  • very tempted to either remove the Polygon2D class or to rename CAG to Polygon2D (they are one and the same !!! )
  • all the CSG.XXX 3D primitives : only the functional variants will remain, perhaps with some minor api changes in order not to lose functionality in the process
0reactions
z3devcommented, Mar 4, 2020

I see no reason to keep this open anymore, as V2 API has been completed, with a few exceptions. If anyone has further comments or issues then please create a new issue. This thread is way too long, and pointless now.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Breaking changes - GitHub Docs
Learn about breaking changes that were introduced in each REST API version. About breaking changes in the REST API. The GitHub REST API...
Read more >
What Are Breaking Changes and How Do You Avoid Them?
What are breaking changes? And how can we avoid them? Here are best practices to avoid and mitigate breaking changes for your API...
Read more >
How to Catch Breaking Changes Before They Happen
Simply put, a breaking change is an update that fails to maintain backward compatibility. With API development, this can be caused by a...
Read more >
How to Discuss API Changes During Code Review - Optic
Breaking changes like mine could probably be prevented with more thorough automated tests, but in many cases, tests are not enough. Let's say ......
Read more >
About API breaking changes - Development - VTK Discourse
ParaView uses VTK as a submodule and usually the developer that update the VTK submodule is responsible for fixing any issue that may...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found