[OpenSCAD] Proposal for extensions to the OpenSCAD syntax

Hugo Jackson hugo at apres.net
Mon Oct 28 15:01:46 EDT 2019


Here’s a very simplistic example of the kind of thing I’m talking about. I’ve created a library of a large number of building blocks of of objects… some are quite simple and others get quite complex… but let’s start with something simple like a tube:



// example A

module tubeA() {
	difference() {
		cylinder(d = 10, h = 25);
		translate([0,0,-.01])
			cylinder(d = 8, h = 25.1);
	}
}



tubeA();



Now that’s okay, if I only want a tube, but if the tube is just a building block then I might easily want to combine it with a larger base...



module tube_standA() {
	tubeA();
	translate([0,0,5])
		cube([20,20,10], center = true);
}

tube_standA();



The problem with that of course is that a straight union of my base with my tube is that it occludes the interior shaft of the tube… so I have to write extra code to bore out the base to accept the tube...


//////////

//example B

module tube_standB() {
	difference() {
		translate([0,0,5])
			cube([20,20,10], center = true);
		translate([0,0,-.01])
			cylinder(d = 9.5, h = 25.1);
	}
	tubeA();
}

tube_standB();

//////////

This strikes me as inelegant, particularly if tube_standB is in and of itself a resusable part that I hope to use somewhere else in one or more of my designs. So at least the dot notation would allow me to create separate modules for union and differencing that would keep the tube definition “intact” and for me personally, make the flow and purpose of the code more straightforward.


// example C

module tubeC() {

	module add() { // do the additive part of the geometry
		cylinder(d = 10, h = 25);
	}
	
	module subtract() { // do the subtractive part of the geometry
		translate([0,0,-.01])
			cylinder(d = 8, h = 25.1);
	}

	difference() {
		add();
		subtract();
	}

}

With the dot notation, then I can create a tube_stand routine that looks ‘cleaner’ to me

module tube_standC() {
	difference() {
		union() {
			translate([0,0,5])
				cube([20,20,10], center = true); // do the additive part of the stand
			tube_standC.add(); // add it to the additive part of the tube
		}
		tube_standC.subtract(); // do the subtractive part of the tube which also subtracts it from the added base
	}
}	


Now as I say, this is a very simple example, and in my more complex routines I’m pretty sure the dot notation would go a long way to make the code more readable and understandable (to me at least).

I appreciate that my enthusiasm for the dot notation may just be a reflection of my own coding style and that I could be just a minority of one that would appreciate this extension to the syntax, and I guess it’s a little bit like the existing dot notation for array access. You can of course write:

value = myArray[1];

But if myArray is a point in 3D space I find it more helpful to use the existing dot notation and write:

value = myArray.y;

You mention, if I understand correctly that you tend to treat files as class containers and the modules within that file as the ‘methods’ of your file’s object. I tend to do that as well, but dot notation would aid in keeping module identifiers much shorter, e.g.

	module myThingAddABitAtTheTopLeft() {}
	module myThingSubtractABitInTheCenter() {}
	module myThingMoveToTheFront() {}

As opposed to say:

	module myThing() {
		module add() {
			module topLeft(){
			}
		module subtract() {
			module atCenter();
		}
		module move() {
			module front() {
			}
		}
	}

And then calling:

	myThing.add.topLeft();
	
	or

	myThing.move.front();





> On Oct 28, 2019, at 11:11 AM, nop head <nop.head at gmail.com> wrote:
> 
> Why do you need to automatic select between drawing an object and making a hole for it? To me they are completely separate operations and I am quite happy to code two separate modules and call them from different places. E.g. I normally subtract the holes from a  panel and then later on I add the object to the panel to make an assembly. If the panel is part of a 3D printed object then the hole subtraction is done in 3D but if it is a milled sheet then the the subtraction is done in 2D and extruded for the assembly view.
> 
> On Mon, 28 Oct 2019 at 18:05, Torsten Paul <Torsten.Paul at gmx.de <mailto:Torsten.Paul at gmx.de>> wrote:
> On 28.10.19 09:51, nop head wrote:
> > Why don't you simply define two modules foo_union()
> > and foo_diff()? 
> 
> That's of cause possible but means there's no way
> to automatically select those.
> 
> > In conventional programming it is bonkers to have
> > combine two completely different bits of code in one
> > function and pass a global variable to decide which
> > one is executed.
> 
> True, but if we can find a way to hide that extra
> logic in a sensible way, that could make objects
> easier to compose. People have asked for that all
> the time.
> The main question is probably if this kind of
> relation can be expressed in a general, independent
> from a specific design.
> 
> ciao,
>   Torsten.
> 
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org <mailto:Discuss at lists.openscad.org>
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191028/35af037c/attachment.html>


More information about the Discuss mailing list