[OpenSCAD] eval( ) ???

Carsten Arnholm arnholm at arnholm.org
Sat May 16 18:08:29 EDT 2015

On 2015-05-16 19:33, G. Wade Johnson wrote:
> Is there a {beta,alpha,prototype} version of OpenSCAD2 somewhere for
> people to play with? Is there a spec to read?
> I, for one, would like to see anything you are willing to share on this.

That was my reaction as well.

In my opinion, classes are not there to complicate things. On the 
contrary, it is an important tool for simplification. Being able to name 
a type, encapsulate its data members and provide member functions would 
go a long way towards the goal of being more expressive without 
complicating things.

In my line of thinking, which may be different from OpenSCAD2 (as I have 
not grasped the full idea of it), the main ideas would be:

classes would be used for constructing named parametric objects 
(instantiation) and being able to union, intersect and difference the 
result with other named or unnamed objects (union(), intersect() and 
difference() would be member functions on any class. unlike a module, a 
class may contain data members unique to each instance created.

Below is just a silly example to illustrate: 2 lollipops on a table.
The difference between a module and a class here is that a class may be 
instantiated and may remember its construction parameters so they can be 
re-used later. It also owns its CSG object.

// classes are new
class lollipop {

    // a constructor is a member function with the same name as the class
    lollipop(rad, diam, hei)
       // keep data members
       radius   = rad;
       diameter = diam;
       height   = hei;

       // "this CSG object"
       this = union() {
          translate([0,0,height]) sphere(r=radius);

    // data members of the class

// modules exist as before
module example_model()
    // create 2 lollipops of different sizes
    // the second is dependent on the first

    lolA = lollipop(rad=10,diam=2,hei=50);
    lolB = lollipop(lolA.radius*2,lolA.diameter*3,lolA.height);

    // create a cube representing the table plate. Here,
    // the construction parameters cannot be accessed later
    // since the cube is a primitive only
    table_plate = cube(size=[100,100,5],center=true);

    // union the lollipops with the table plate and return it

    // be explicit about what the module returns
    return table_plate;

// construct the exmple model and export it as STL

You could go on, classes could have data members being instantiations of 
other classes, or even containers containing such.

The above is just meant as a supplement to what I wrote before, 
illustrating the idea that the OpenSCAD language could be extended in a 
direction which would be immediately recognisable to programmers, while 
still being backwards compatible with existing OpenSCAD code. If you 
want to express things as it is currently being done, you can, but you 
also have other possibilities.

Again, just my thoughts. I don't know if it would be easy to implement.


More information about the Discuss mailing list