Restructure code, seperate 'core' from helpers & modeling api about csg.js HOT 10 CLOSED

Does this include refactoring the math objects?
I think that should happen first, which would include some movement of functionality, API changes, and splitting out utilities.
Probably not so large, but important for making changes in higher level functions.

from csg.js.

To be honest I consider it all in the same basket at this stage, so that also includes all the maths and stuff
not going to split up the split up :) at least for now I do not see things clearly enough, and untangling all the dependencies is going to be painful.

from csg.js.

I guess then it all depends on what the goal is at the end. There haven't been any improvements in performance, so there's lots of low hanging fruit. At this point, I still think that major API changes would be unwelcome. But maybe that would be a natural consequence of the cleanup.

from csg.js.

Hmm there is a bit of misunderstanding then, I thought we agreed on doing breaking changes at this point, in order to finally clean up the api ?

from csg.js.

Definitely some things have to change due to the new functional approach.

So, first question...

Is there any point at keeping the old API. For example, circle() becomes a function. Does CAG.circle() continue to exist? I think not but let me know otherwise.

from csg.js.

• For a while we can continue to alias functions/objects when possible: even our recent changes have already changed the internals (if you take a look here , it is a LOT of aliases https://github.com/jscad/csg.js/blob/master/csg.js)
• I do not even know where I got this bad impression / habbit from but a LOT of the 'shapes api' in CSG.js should not be used with a new CSG.X() syntax at all : ie new CSG.cube() is wrong, it should be just const myBox = CSG.cube() (they are not constructors!): ie a lot of stuff is already just functions

About Merging csg.js and scad-api

• even if the code is messy , scad-api is a very clearly defined API : all of the functions in it are the API, unlike in CSG.js where the difference between internal code and user facing API is very muddy

• I can read the tests and know the different parameters used and get an API outline real fast

• with a bit of cleanup it looks way better and clearer (see my recent PR : https://github.com/jscad/scad-api/pull/29/files#diff-6967034af8884bc0784a38ac5706e6d1R248)

• CSG.js and scad-api are very closely related, and if we want to seperate core features from modeling/helpers, then there is little to no difference between the 'modelling/helpers' code as API and scad-api:

  • so we stop calling it scad-api , it becomes just the functional modeling part of our API
  • it will still be sufficiently similar to openscad syntax to ease the transition, no matter what
  • but we fix any coherency issues with it , even if that means breaking changes
  • we also merge together the 'identical parts' (between CSG & scad-api), retaining some of the different syntax from CSG.js when applicable : ie we want to end up with a single cube() function that is versatile, a single circle() function etc
  • whenever possible/applicable: any code in scad-api that is just a wrapper around CSG features (like extrude) becomes a single piece of code
  • we still want to keep the essence of an API though: ie : the API needs to be somewhat decoupled from the core : ie even IF someone would create a totally different CSG.js from scratch that is better, we should be able to keep our modeling API intact (interface !== implementation)

• we would end up possibly with 2 'sub packages' core and API, perhaps subpackages like IO is a good fit, I am not 100% sure of this yet

from csg.js.

hmm rereading some of my points I have some doubts : ie we really want to avoid coupling the core and API too closely

from csg.js.

All good points above. Thanks for taking the time to outline the changes.

There are a few functions that will come from the CSG library as well, such as expand(), contract(), etc. I presume that these will be retained as part of the API.

Yeah. We ovbously want the core library very tight. So the question about an API library/ project becomes interesting. Maybe after seeing the core, the API will be cleaner and clear.

from csg.js.

Should be pure functional approach going forward.
const obj = CSG.circle()

Which brings up a few questions...

• there's over lap between JCSAD API and SCAD API

  • can/should both be used in JSCAD scripts?
  • should the SCAD API be discarded? Merge everything to JSCAD API.

• this makes core really small, I.e those classs that need the new operator

  • does everything else make sense as either API or UTILS?

from csg.js.

done by #87 , closing

from csg.js.