Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve source structure? #169

Open
jeff-dh opened this issue May 18, 2021 · 5 comments
Open

Improve source structure? #169

jeff-dh opened this issue May 18, 2021 · 5 comments

Comments

@jeff-dh
Copy link
Contributor

jeff-dh commented May 18, 2021

After spending a couple of days studying the SolidPython code I would like to propose an idea which -- I think -- would make the code more maintainable and extendable.

As far as I understand the code, it consists of two major parts:

  1. solid.*(".core"?):
    - is basically everything in objects.py and solidpython.py
    - is the actuall "interface" to OpenSCAD and provides everything for a pretty straight forward 1:1 mapping of all OpenSCAD features
  2. solid.utils (or "extensions"?):
    - everything else
    - these are "libraries" extending the features of OpenSCAD (e.g. extrude_along_path, splines,...)

The actual code structure is the following (as far as I understand it):

  • objects.py & solidpython.py contain "solid.core". These files contain:
    - [Included]OpenSCADObject
    - builtins (e.g. circle, square, translate, hull,....)
    - import scad functions (a couple of functions, some in objects.py, some in solidpython.py)
    - rendering functions (scad_render* in solidpython.py)

  • everything else in the solid directory are "extensions":
    - extrude_along_path.py
    - patch_euclid.py
    - screw_thread.py
    - splines.py
    - utils.py

I would suggest the following two changes:

  1. move all extensions into a subdirectory (suggestion solid/extensions)
    - add a new solid/utils.py file that only imports everything from solid/extensions to stay backward compatible
    - alternatively we could create a solid/utils package (directory) that contains all the extensions

  2. break up objects.py and solidpython.py into several modules, I would suggest the following:
    1. helpers.py - contains common used helper functions
    2. object_base.py - contains [Include]OpenSCADObject - the object tree
    3. builtins.py - contains all the python wrappers for the OpenSCAD builtins
    4. scad_render.py - contains everything for generating *.scad files from the object tree
    5. scad_import.py - contains everything for importing *.scad files

Note: Even though the Part/Hole feature (and maybe BOM too) are -- from my point of view -- technically "extensions" it would be pretty hard to extract them from solid.core and I would suggest to not touch them.

I have a local branch where I've made exactly the described changes. It includes the refactoring to the explained structure but also the usage of py_scadparser and dynamic_builtins.
It's definitely not ready to ship code but the "core" looks pretty good to me even though it was not tested extensively. Some stuff might even be broken atm (e.g. the extensions, tests, examples).

I tried to touch as little code as possible and the branch should not contain any other changes besides the structure, the parser and the builtins.

Are you interested in somehow integrating the "structure change" into SolidPython?

I'll attach the branch to this thread.

Btw: I really appreciate the work you did and I am excited about SolidPython. Great work! (especially to keep it up for such a long time)

@jeff-dh
Copy link
Contributor Author

jeff-dh commented May 18, 2021

Hmmm can't figure out how to attach a branch to this thread without adding a noop commit.......

So here you go:
https://github.com/jeff-dh/SolidPython/tree/exp_code_structure

@etjones
Copy link
Contributor

etjones commented May 18, 2021

Dude! You've pretty much been through this whole project, diagnosing problems and proposing great solutions all through! I think that's excellent and I'm looking forward to integrating the issues you've pointed out. It'll also take me a while (a couple weeks?) to catch up with all the work you've already done.

I'm most inclined to handle the feature fixes/improvements first, and then take a look at project organization after that. I'm not opposed to shifting things around some, but my experience has been that everybody slices up a project a little differently, with one person's crystal-clear improvements being another person's excessive abstraction, etc. So... a code re-org isn't at the top of my priority list just yet, but I'll look at this in more detail once I've looked at the other contributions you've made. Thanks for taking such a deep look at this project!

@jeff-dh
Copy link
Contributor Author

jeff-dh commented May 18, 2021

Yeah, I absolutely see your point.

Additionally it would definitely introduce new bugs and probably break some features that are working atm.

It just becomes harder and harder to back port features ;)

@jeff-dh
Copy link
Contributor Author

jeff-dh commented May 30, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants