Nabble has removed Mailing-list integration.
Posts created here DO NOT GET SENT TO THE MAILING LIST.
Mailing-list emails DO NOT GET POSTED TO THE FORUM.
So basically the Forum is now out of date, we are looking into migrating the history.
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();
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I never get that situation because all my objects are described by list of parameters. So I would just linear_extrude the difference between a square and a circle with tubes ID using a function to access that. If it was a more complicated inner shape I would expose it as a module. You seem to be calling inner modules but what if they use parameters and local variables of the outer module? You haven't instantiated the module so they don't have any values. In normal OO languages objects have instance variables and methods have both local variables and access to the instance variables. I use a list to hold my instance data. There isn't really an equivalent with OpenSCAD modules. Are all the parameters and local variables, the instance variables of the object? It just doesn't make any sense to me. On Mon, 28 Oct 2019 at 19:02, Hugo Jackson <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |