discuss@lists.openscad.org

OpenSCAD general discussion

View all threads

Redefining core modules

JB
Jordan Brown
Sun, Sep 5, 2021 12:11 AM

Every once in a while, discussions come up about the possibility of
having OpenSCAD programs or libraries redefine core modules.

You can do it, and for may of the modules (e.g. cube()) it's
straightforward to see how to implement the new module in terms of
lower-level primitives.

But there always ends up being a roadblock:  some of the operations are
so primitive that they can't be implemented in terms of others. 
Multmatrix, polyhedron, and polygon are the primary ones that get
mentioned, but linear_extrude and a number of the others have similar
problems.  There can't be turtles all the way down
https://en.wikipedia.org/wiki/Turtles_all_the_way_down.

People have proposed schemes that would allow one to override primitives
while still allowing access to the underlying implementation, typically
by having the core export aliases like "__multmatrix".

I had an idea, and tested it, and found that there's already a general
way to do this.  It relies on the fact that if file A does a "use" of
file B, file B doesn't see modules defined by file A.

--- mmtest.scad ---

use <multmatrix.scad>

m = [
    [ 1, 0, 0, 0 ],
    [ 0, 1, 0, 0 ],
    [ 0, 0, 2, 0 ],
    [ 0, 0, 0, 1 ]
    ];
multmatrix(m) cube(10);

--- multmatrix.scad ---

use <multmatrix2.scad>

module multmatrix(m) {
    echo("new multmatrix");
    _multmatrix(m) children();
}

--- multmatrix2.scad ---

module _multmatrix(m) {
    multmatrix(m) children();
}

Enjoy(?).

Every once in a while, discussions come up about the possibility of having OpenSCAD programs or libraries redefine core modules. You can do it, and for may of the modules (e.g. cube()) it's straightforward to see how to implement the new module in terms of lower-level primitives. But there always ends up being a roadblock:  some of the operations are so primitive that they can't be implemented in terms of others.  Multmatrix, polyhedron, and polygon are the primary ones that get mentioned, but linear_extrude and a number of the others have similar problems.  There can't be turtles all the way down <https://en.wikipedia.org/wiki/Turtles_all_the_way_down>. People have proposed schemes that would allow one to override primitives while still allowing access to the underlying implementation, typically by having the core export aliases like "__multmatrix". I had an idea, and tested it, and found that there's already a general way to do this.  It relies on the fact that if file A does a "use" of file B, file B doesn't see modules defined by file A. --- mmtest.scad --- use <multmatrix.scad> m = [ [ 1, 0, 0, 0 ], [ 0, 1, 0, 0 ], [ 0, 0, 2, 0 ], [ 0, 0, 0, 1 ] ]; multmatrix(m) cube(10); --- multmatrix.scad --- use <multmatrix2.scad> module multmatrix(m) { echo("new multmatrix"); _multmatrix(m) children(); } --- multmatrix2.scad --- module _multmatrix(m) { multmatrix(m) children(); } --- Enjoy(?).
JB
Jordan Brown
Sun, Sep 5, 2021 12:49 AM

I should note that I am not at all sure whether it is a good idea for
people to redefine core modules.

I should note that I am not at all sure whether it is a good *idea* for people to redefine core modules.
NH
nop head
Sun, Sep 5, 2021 7:57 AM

Nice. I thought about the problem with multmatrix when we were discussing
augmenting the transformations to keep track of the local transformation
matrix.

On Sun, 5 Sept 2021 at 01:49, Jordan Brown openscad@jordan.maileater.net
wrote:

I should note that I am not at all sure whether it is a good idea for
people to redefine core modules.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

Nice. I thought about the problem with multmatrix when we were discussing augmenting the transformations to keep track of the local transformation matrix. On Sun, 5 Sept 2021 at 01:49, Jordan Brown <openscad@jordan.maileater.net> wrote: > I should note that I am not at all sure whether it is a good *idea* for > people to redefine core modules. > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >