[OpenSCAD] Proposal for extensions to the OpenSCAD syntax

nop head nop.head at gmail.com
Mon Oct 28 21:01:16 EDT 2019


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 <hugo at apres.net> wrote:

> 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> 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
>> 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
>
>
> _______________________________________________
> 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/20191029/eedcc00d/attachment.html>


More information about the Discuss mailing list