Node editing systems for 3D and drawing

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Node editing systems for 3D and drawing

OpenSCAD mailing list-2
My thanks to Doug Moen for pointing out Blender's node functionality which I
was not previously aware of.

To ensure that my ignorance becomes less, I would appreciate anything which
folks could share to expand/correct the following:

 - Rhino has an optional node system, Grasshopper which affords full control
of models?
 - Blender --- in addition to the native node system (for materials only?)
there is an add-on modeled on Grasshopper:
http://nikitron.cc.ua/sverchok_en.html

For OpenSCAD and similar tools there is:

 - OpenJSCAD --- version of this in the Microsoft Store, also available on
the web
 - BlockSCAD
 - https://github.com/studiotc/NodeGraphInterface
 - clikscad
 - Antimony/Kokopelli --- I wish this ran on Windows --- I may break down
and get a Mac at some point, or find time to set up a Linux box, but it's
unfortunate that access to it is so limited

For 2D similar tools include:

 - Processing --- programming based on JavaScript --- its use for
CNC/CAD/CAM is described in the book _Make: Design for CNC Furniture
Projects and Fabrication Technique_
 - Nodebox --- elegant programmatic 2D drawing with nodes --- unfortunately,
units in graphics (PDFs or SVGs) are rounded off, so only suited to
decorative use, or use with single-piece projects (a sundial has been done)

CAM-specific tools include:

 - Maker.JS --- a Microsoft Garage project extending node.js for making
things
 - Tool Path Language --- an opensource extension of JavaScript to create
G-Code for directly controlling machines

Is there anything else which I've missed? I'd welcome any additions or
corrections. It's all going on:

 - https://wiki.shapeoko.com/index.php/OpenSCAD
 - https://wiki.shapeoko.com/index.php/CAD
 - https://wiki.shapeoko.com/index.php/Programming

For my part, things I'd like to see:

 - BlockSCAD available as an alternate interface in OpenSCAD:
https://github.com/openscad/openscad/issues/3108
 - BlockSCAD support for the Customizer:
https://github.com/EinsteinsWorkshop/BlocksCAD/issues/48
 - a formal technique/site for placing OpenSCAD projects online which isn't
Thingiverse

OpenSCAD support for drawing in 2D --- I'm currently re-creating projects in
METAPOST using lualatex:
https://wiki.shapeoko.com/index.php/Design_into_3D:_box:_fitted and
https://github.com/WillAdams/Design_Into_3D/tree/master/box/fitted --- maybe
there's a better way to do this? I was successful with modeling a Chinese
Checkers board and projecting it into 2D so as to export a DXF:
https://community.carbide3d.com/t/design-into-3d-games-chinese-checkers/16056

William




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

OpenSCAD mailing list-2
And it turns out I missed a node editor for FreeCAD:

https://forum.freecadweb.org/viewtopic.php?t=36299



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

Robin2
Forgive my ignorance but what is a "Node editing system" and in what context
is it relevant to OpenSCAD ?

...R



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

OpenSCAD mailing list-2
It's the description of connected block diagramming/programming tools --- the
discussion of your program spurred the mention of Blender having such an
interface, and I'd like to fill in any gaps on such systems.

Is there some other terminology you feel would be better, or which you would
prefer for describing Clikscad?

William



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

tp3
In reply to this post by OpenSCAD mailing list-2
On 27.10.19 12:01, WillAdams via Discuss wrote:
>  - BlockSCAD support for the Customizer:
> https://github.com/EinsteinsWorkshop/BlocksCAD/issues/48

That repo seems to be dead for 3 years.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

Robin2
In reply to this post by OpenSCAD mailing list-2
OpenSCAD mailing list-2 wrote
> It's the description of connected block diagramming/programming tools ---
> the
> discussion of your program spurred the mention of Blender having such an
> interface, and I'd like to fill in any gaps on such systems.
>
> Is there some other terminology you feel would be better, or which you
> would
> prefer for describing Clikscad?

The word "node" conjured up in my mind the point where two sides of a
polygon intersect so I thought you were referring to something that would
make it easy to create or edit a polygon or its 3D equivalent.

I don't really have any suggestion for the terminology.

I use the word "element" to describe the parts in one of my ClikScad models.
An element could be a cube, a sphere, a difference, a module etc.  When
ClikScad creates the OpenSCAD code every one of those will be in an OpenSCAD
module as that seemed to me the simplest way for my Python code to do
things.

...R



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

doug.moen
In reply to this post by OpenSCAD mailing list-2
Instead of "Node editing system", I would suggest the more general term "Visual programming language".

https://en.wikipedia.org/wiki/Visual_programming_language

There is a (very incomplete) list of visual programming languages in that Wikipedia article.

For example, Sketch-n-sketch belongs in your list: it is a programming language for generating SVG models, which also lets you edit your source code by direct manipulation of the SVG model that is produced as the output. But, it isn't a node-editing system. The authors call it a "direct manipulation programming system", but I think it belongs in the category of visual programming languages.

https://ravichugh.github.io/sketch-n-sketch/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

OpenSCAD mailing list-2
Doug Moen <[hidden email]> wrote:

>Instead of "Node editing system", I would suggest the more general term "Visual programming language".

https://en.wikipedia.org/wiki/Visual_programming_language

Agreed.

>....

For example, Sketch-n-sketch belongs in your list: it is a programming language for generating SVG models, which also lets you edit your source code by direct manipulation of the SVG model that is produced as the output. But, it isn't a node-editing system. The authors call it a "direct manipulation programming system", but I think it belongs in the category of visual programming languages.

https://ravichugh.github.io/sketch-n-sketch/

Thanks! That one is new to me and looks quite promising. Adding and looking into it now.

William

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Proposal for extensions to the OpenSCAD syntax

boxcarmib

I've been working with OpenSCAD for a couple of years now, and while frustrating I appreciate problematic nature of the inherent
limitations, like being unable to interrogate values.

I have been playing around with ways in which the basic syntax might be extended that would provide more
flexibility and power in creating 3D models. I'm no computer language expert, but I think the extensions
I propose would ease a lot of frustrations with some of the inherent limitations of the language without
breaking any of the rules.

To start, I would propose an extension of the "dot" notation, that would allow one to refer to a value declaration and/or
function or module component of another module with a dot.

e.g.

module foo() {
        valueA = 7;
        valueB = 3;
       
        function myFunc(num) = valueA + num;
       
        cube([valueA, valueB, valueB]);
}

module bar() {
        valueB = 8;

        valueC = foo.valueA + foo.myFunc(valueB); // use the myFunc function of foo to calculate valueC
       
        cube([valueA, valueB, valueC])
        foo();

}

Scoping rules would remain as they are, in that value declarations would be at the scope of the called module or module part. i.e. for the
above example the cube created in module bar, valueB would = 8 but it would be 3 in foo.


The second extension would be the election of three operations as 'reserved' functions, union, difference and intersection such that one
could explicitly call that part of a module without calling the others:

module foo() {
        valueA = 7;
       
        intersection : {
                cylinder(d = 7, h = 4);
        }

        difference : {
                cube([8,3,2]);
        }

        union : {
                translate([9,3,3])
                        cube([3,1,1]);
        }
}

module bar() {
        valueG = foo.valueA;
       
       
        foo.union(); // would only execute foo.union;
        foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
       
}

One could select the execution of nested module definitions in another module as well… not just the ‘reserved’ functions.

This would allow for a tighter coupling of a module's attributes to it's basic geometry. Simplistically, say one wants a walled cylinder but it will
this part would have differing bases depending on where the cylinder was used in a design. As it stands, one would need to either create
cumbersome code for the cylinder base to avoid the base cylinder definition to avoid 'filling' up the cylinder where the base was, or decouple
the difference operation from the declaration of the cylinder so it will clear out any of the base geometry that is placed in the
way of the shaft.

These two extensions of the syntax would also allow for comparatively effortless calculation of boundary regions where desired without
creating a performance penalty where it is not needed and provide for pseudo polling of an objects characteristics without actually
requiring access to unreachable object values.

I hope that what I see as a manifold increase in the expressive power and abstraction in creating openSCAD programs with these
suggestions for an extended syntax or self-evident... and I'd be interested in what the rest of you might think. If what I’m suggesting is unclear
Please let me know… I didn’t want to bog this proposal down with details if it’s obvious, but in doing that I have taken the risk that the improvement
And benefits of such extensions may not be evident.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

tp3
First note that the function literals are now
implemented, so the snapshot version of OpenSCAD
has functions as first class values which means
support for higher order functions.
(https://github.com/openscad/openscad/pull/3077)

I hope to find some time to collect notes and post
an article about it. Meanwhile the minimalist docu
can be found at
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals

On 28.10.19 00:09, Hugo Jackson wrote:
> To start, I would propose an extension of the "dot"
> notation, that would allow one to refer to a value
> declaration and/or function or module component of
> another module with a dot.

Yes, having access to a nested data structure is
definitely something that would help a lot. The
core changes to the parser implementation that are
required for this are now done and merged to the
development snapshot.

But I don't think it will be possible to link to
the existing function and/or module definitions.

Slightly modified example, just adding a parameter
to module foo():

module foo(offset) {
        valueA = 7 + offset;

        function myFunc(num) = valueA + num;
}

module bar() {
        valueB = 8;

        valueC = foo.valueA + foo.myFunc(valueB);
}

foo(10);
translate([10, 10, 0]) foo(20);

bar(); // <- now what is valueC ?


> The second extension would be the election of three
> operations as 'reserved' functions, union, difference
> and intersection such that one could explicitly call
> that part of a module without calling the others:

I'm not sure I understand how this will work. Why
select specifically those 3 special cases?

Is that meant just as names or would that also mean
intersection() { bar(); foo(); } a bit like operator
overloading?

> foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}

Where's the nesting coming from? From the order of
the definitions?

> Please let me know… I didn’t want to bog this
> proposal down with details if it’s obvious, but in
> doing that I have taken the risk that the improvement
> And benefits of such extensions may not be evident.

Yes, more details are always good in that discussion.

See also https://github.com/openscad/openscad/pull/3087
which is implementing a similar proposal mostly as
reference for discussion.

More discussion can be found in
https://github.com/openscad/openscad/issues/3088

It would be great if we can find a definition that
works nicely as addition without breaking existing
scripts.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

boxcarmib


> On Oct 27, 2019, at 5:13 PM, Torsten Paul <[hidden email]> wrote:
>
> First note that the function literals are now
> implemented, so the snapshot version of OpenSCAD
> has functions as first class values which means
> support for higher order functions.
> (https://github.com/openscad/openscad/pull/3077)
>
> I hope to find some time to collect notes and post
> an article about it. Meanwhile the minimalist docu
> can be found at
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals
>
> On 28.10.19 00:09, Hugo Jackson wrote:
>> To start, I would propose an extension of the "dot"
>> notation, that would allow one to refer to a value
>> declaration and/or function or module component of
>> another module with a dot.
>
> Yes, having access to a nested data structure is
> definitely something that would help a lot. The
> core changes to the parser implementation that are
> required for this are now done and merged to the
> development snapshot.
>
> But I don't think it will be possible to link to
> the existing function and/or module definitions.
>
> Slightly modified example, just adding a parameter
> to module foo():
>
> module foo(offset) {
> valueA = 7 + offset;
>
> function myFunc(num) = valueA + num;
> }
>
> module bar() {
> valueB = 8;
>
> valueC = foo.valueA + foo.myFunc(valueB);
> }
>
> foo(10);
> translate([10, 10, 0]) foo(20);
>
> bar(); // <- now what is valueC ?
>

Good point… for my part I don’t usually code modules with parameters, but I appreciate that isn’t how the real world works. :)
But I would think that calling any module part or function would require an enumeration of all needed values in the parameter arguments, e.g. for the example you
provide the call for valueC in bar would need to be:

valueC = foo(offset = 7).valueA + foo(offset = 7).myFunc(valueB) … or literally valueC = foo(7).valueA + foot(7).myFunc(valueB)

Perhaps that would lead to a preponderance of code that would only serve to make code look more tortuous than it already does. Yet I think the
proposed ‘dot’ syntax would lead to more insightful coding that would tend to mitigate the damage that might occur.

>
>> The second extension would be the election of three
>> operations as 'reserved' functions, union, difference
>> and intersection such that one could explicitly call
>> that part of a module without calling the others:
>
> I'm not sure I understand how this will work. Why
> select specifically those 3 special cases?
>
> Is that meant just as names or would that also mean
> intersection() { bar(); foo(); } a bit like operator
> overloading?
>
>> foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
>
> Where's the nesting coming from? From the order of
> the definitions?
>
>> Please let me know… I didn’t want to bog this
>> proposal down with details if it’s obvious, but in
>> doing that I have taken the risk that the improvement
>> And benefits of such extensions may not be evident.



I often code modules using a special varialble I name $e and a skeleton module that looks like this:

module foo($e = -1) {
        module _union() {
                // code that primarily builds the object
        }

        module _diff() {
                // code that primarily subtracts geometry from _union()
        }

        difference() {
                if($e == -1 || $e == 0)
                        _union();
                if($e == -1 || $e == 1)
                        _diff();
        }
}

I then get to call foo and either get just the _union code or just the _diff code or have the object definition run completely when $e == -1

With this approach, when I just want the foo object I simply write:

foo();

But if I want the foo object to be united with some other objects before any difference is applied I could do it like this:

module bar() {
        difference() {
                union() {
                        foo($e = 0);
                        cylinder(d = 5, h = 10);
                }
                foo($e = 1);
        }
}

I find that this kind of approach helps with the overall flow and data abstraction, but the addition of a special variable and the requirement for the difference(){union() {}} code to make it work detracts from what I feel is overall a more elegant approach, and I find it particularly helpful for code reuse.
So that’s really what my suggestion for ’reserved’ functions is about.. following the logic that you would execute union functionality before difference because you need to have first constructed an object before you remove anything from it. Don’t almost all modules have the…

difference() {
        union() {
                // add some stuff
        }
        // take some stuff away
}

construct in them?

So that’s why I was thinking that a syntax that supported what I have at least found to be the most common code construction would make code more readable, so that I would just write:

module foo() {

        union : {
                // code that primarily builds the object
        }
        diff : {
                // code that primarily subtracts geometry from union()
        }

        // code that follows executes only if foo is called
}

Now when I want the foo object to be combined with other objects, I would just have to write:

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Perhaps there may be a more elegant way of structuring things, but I was aiming at a syntax that while not backwards compatible, wouldn’t break anything that was already working.

Thanks for the heads up on the availability of function literals… that should make life more fun and exciting. And thanks for the links to the discussion lists.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

nophead
Instead of 

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Why don't you simply define two modules foo_union() and foo_diff()? 

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.

In my case I would have foo(type), foo_holes(type) where type is a list with all the parameters and I have accessor functions such as foo_width(type).

If there is common positioning between foo() and foo_holes() then I would have foo_hole_positions(type) that positions children().

On Mon, 28 Oct 2019 at 04:25, Hugo Jackson <[hidden email]> wrote:


> On Oct 27, 2019, at 5:13 PM, Torsten Paul <[hidden email]> wrote:
>
> First note that the function literals are now
> implemented, so the snapshot version of OpenSCAD
> has functions as first class values which means
> support for higher order functions.
> (https://github.com/openscad/openscad/pull/3077)
>
> I hope to find some time to collect notes and post
> an article about it. Meanwhile the minimalist docu
> can be found at
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals
>
> On 28.10.19 00:09, Hugo Jackson wrote:
>> To start, I would propose an extension of the "dot"
>> notation, that would allow one to refer to a value
>> declaration and/or function or module component of
>> another module with a dot.
>
> Yes, having access to a nested data structure is
> definitely something that would help a lot. The
> core changes to the parser implementation that are
> required for this are now done and merged to the
> development snapshot.
>
> But I don't think it will be possible to link to
> the existing function and/or module definitions.
>
> Slightly modified example, just adding a parameter
> to module foo():
>
> module foo(offset) {
>       valueA = 7 + offset;
>
>       function myFunc(num) = valueA + num;
> }
>
> module bar() {
>       valueB = 8;
>
>       valueC = foo.valueA + foo.myFunc(valueB);
> }
>
> foo(10);
> translate([10, 10, 0]) foo(20);
>
> bar(); // <- now what is valueC ?
>

Good point… for my part I don’t usually code modules with parameters, but I appreciate that isn’t how the real world works. :)
But I would think that calling any module part or function would require an enumeration of all needed values in the parameter arguments, e.g. for the example you
provide the call for valueC in bar would need to be:

valueC = foo(offset = 7).valueA + foo(offset = 7).myFunc(valueB) … or literally valueC = foo(7).valueA + foot(7).myFunc(valueB)

Perhaps that would lead to a preponderance of code that would only serve to make code look more tortuous than it already does. Yet I think the
proposed ‘dot’ syntax would lead to more insightful coding that would tend to mitigate the damage that might occur.

>
>> The second extension would be the election of three
>> operations as 'reserved' functions, union, difference
>> and intersection such that one could explicitly call
>> that part of a module without calling the others:
>
> I'm not sure I understand how this will work. Why
> select specifically those 3 special cases?
>
> Is that meant just as names or would that also mean
> intersection() { bar(); foo(); } a bit like operator
> overloading?
>
>> foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
>
> Where's the nesting coming from? From the order of
> the definitions?
>
>> Please let me know… I didn’t want to bog this
>> proposal down with details if it’s obvious, but in
>> doing that I have taken the risk that the improvement
>> And benefits of such extensions may not be evident.



I often code modules using a special varialble I name $e and a skeleton module that looks like this:

module foo($e = -1) {
        module _union() {
                // code that primarily builds the object
        }

        module _diff() {
                // code that primarily subtracts geometry from _union()
        }

        difference() {
                if($e == -1 || $e == 0)
                        _union();
                if($e == -1 || $e == 1)
                        _diff();
        }               
}

I then get to call foo and either get just the _union code or just the _diff code or have the object definition run completely when $e == -1

With this approach, when I just want the foo object I simply write:

foo();

But if I want the foo object to be united with some other objects before any difference is applied I could do it like this:

module bar() {
        difference() {
                union() {
                        foo($e = 0);
                        cylinder(d = 5, h = 10);
                }
                foo($e = 1);
        }
}

I find that this kind of approach helps with the overall flow and data abstraction, but the addition of a special variable and the requirement for the difference(){union() {}} code to make it work detracts from what I feel is overall a more elegant approach, and I find it particularly helpful for code reuse.
So that’s really what my suggestion for ’reserved’ functions is about.. following the logic that you would execute union functionality before difference because you need to have first constructed an object before you remove anything from it. Don’t almost all modules have the…

difference() {
        union() {
                // add some stuff
        }
        // take some stuff away
}

construct in them?

So that’s why I was thinking that a syntax that supported what I have at least found to be the most common code construction would make code more readable, so that I would just write:

module foo() {

        union : {
                // code that primarily builds the object
        }
        diff : {
                // code that primarily subtracts geometry from union()
        }

        // code that follows executes only if foo is called
}

Now when I want the foo object to be combined with other objects, I would just have to write:

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Perhaps there may be a more elegant way of structuring things, but I was aiming at a syntax that while not backwards compatible, wouldn’t break anything that was already working.

Thanks for the heads up on the availability of function literals… that should make life more fun and exciting. And thanks for the links to the discussion lists.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Node editing systems for 3D and drawing

Robin2
In reply to this post by doug.moen
doug.moen wrote
> Instead of "Node editing system", I would suggest the more general term
> "Visual programming language".

I would prefer "Visual Programming System" rather than "Visual Programming
Language".

I don't think Graphscad, Blockscad or my ClikScad are languages. They are
just graphical systems to make programming easier with the OpenSCAD
language.

On the other hand I would consider SolidPython and OpenPyscad to be
languages as they are essentially extensions to the Python language and you
would need to be familiar with regular Python programming to use them. And
they are not really "visual" systems.

...R



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

boxcarmib
In reply to this post by nophead


On Oct 28, 2019, at 1:51 AM, nop head <[hidden email]> wrote:

Instead of 

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Why don't you simply define two modules foo_union() and foo_diff()? 

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.

In my case I would have foo(type), foo_holes(type) where type is a list with all the parameters and I have accessor functions such as foo_width(type).

If there is common positioning between foo() and foo_holes() then I would have foo_hole_positions(type) that positions children().

I take your point, and the distributed functionality of the modules you recommend is something I have tried and eventually abandoned… I think I just found the proliferation of modules a little unsatisfying.

I think my current direction is shaped by my experience with object oriented programming… indeed, in OpenSCAD I’m primarily creating actual objects :)

So to my way of thinking, and I’d be the first to concede that I may not have the experience to really warrant an opinion, some adoption of object oriented philosophy would improve the OpenSCAD programming experience even if its not an object oriented language.

So while in a conventional imperative language it may be insane to combine two bits of code whose execution is selected by a passed parameter, what I’m trying to do is get at least some feel for a more oo like environment even though the language doesn’t support it, and my proposal to do that is part of that goal, and that’s the reason for my proposal of extended dot notation… the ability to call the ‘methods’ of OpenSCAD objects seems natural to me.

The second part of the proposal whether it’s accomplished with labels or ‘reserved’ methods is just my attempt to suggest something that might feel something like the constructor/destructor functions of an oo object. With ‘real’ objects like in OpenSCAD I liken the union method to a constructor and the difference/intersection functionality to a destructor and my proposal was aimed at incorporating the benefits of that kind of structure to an OpenSCAD program.

Anyway, thanks for you feedback, it's helping me to develop a better understanding of what I’m wishing for, even if that desire is unrealistic, impractical or unachievable.



On Mon, 28 Oct 2019 at 04:25, Hugo Jackson <[hidden email]> wrote:


> On Oct 27, 2019, at 5:13 PM, Torsten Paul <[hidden email]> wrote:
>
> First note that the function literals are now
> implemented, so the snapshot version of OpenSCAD
> has functions as first class values which means
> support for higher order functions.
> (https://github.com/openscad/openscad/pull/3077)
>
> I hope to find some time to collect notes and post
> an article about it. Meanwhile the minimalist docu
> can be found at
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals
>
> On 28.10.19 00:09, Hugo Jackson wrote:
>> To start, I would propose an extension of the "dot"
>> notation, that would allow one to refer to a value
>> declaration and/or function or module component of
>> another module with a dot.
>
> Yes, having access to a nested data structure is
> definitely something that would help a lot. The
> core changes to the parser implementation that are
> required for this are now done and merged to the
> development snapshot.
>
> But I don't think it will be possible to link to
> the existing function and/or module definitions.
>
> Slightly modified example, just adding a parameter
> to module foo():
>
> module foo(offset) {
>       valueA = 7 + offset;
>
>       function myFunc(num) = valueA + num;
> }
>
> module bar() {
>       valueB = 8;
>
>       valueC = foo.valueA + foo.myFunc(valueB);
> }
>
> foo(10);
> translate([10, 10, 0]) foo(20);
>
> bar(); // <- now what is valueC ?
>

Good point… for my part I don’t usually code modules with parameters, but I appreciate that isn’t how the real world works. :)
But I would think that calling any module part or function would require an enumeration of all needed values in the parameter arguments, e.g. for the example you
provide the call for valueC in bar would need to be:

valueC = foo(offset = 7).valueA + foo(offset = 7).myFunc(valueB) … or literally valueC = foo(7).valueA + foot(7).myFunc(valueB)

Perhaps that would lead to a preponderance of code that would only serve to make code look more tortuous than it already does. Yet I think the
proposed ‘dot’ syntax would lead to more insightful coding that would tend to mitigate the damage that might occur.

>
>> The second extension would be the election of three
>> operations as 'reserved' functions, union, difference
>> and intersection such that one could explicitly call
>> that part of a module without calling the others:
>
> I'm not sure I understand how this will work. Why
> select specifically those 3 special cases?
>
> Is that meant just as names or would that also mean
> intersection() { bar(); foo(); } a bit like operator
> overloading?
>
>> foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
>
> Where's the nesting coming from? From the order of
> the definitions?
>
>> Please let me know… I didn’t want to bog this
>> proposal down with details if it’s obvious, but in
>> doing that I have taken the risk that the improvement
>> And benefits of such extensions may not be evident.



I often code modules using a special varialble I name $e and a skeleton module that looks like this:

module foo($e = -1) {
        module _union() {
                // code that primarily builds the object
        }

        module _diff() {
                // code that primarily subtracts geometry from _union()
        }

        difference() {
                if($e == -1 || $e == 0)
                        _union();
                if($e == -1 || $e == 1)
                        _diff();
        }               
}

I then get to call foo and either get just the _union code or just the _diff code or have the object definition run completely when $e == -1

With this approach, when I just want the foo object I simply write:

foo();

But if I want the foo object to be united with some other objects before any difference is applied I could do it like this:

module bar() {
        difference() {
                union() {
                        foo($e = 0);
                        cylinder(d = 5, h = 10);
                }
                foo($e = 1);
        }
}

I find that this kind of approach helps with the overall flow and data abstraction, but the addition of a special variable and the requirement for the difference(){union() {}} code to make it work detracts from what I feel is overall a more elegant approach, and I find it particularly helpful for code reuse.
So that’s really what my suggestion for ’reserved’ functions is about.. following the logic that you would execute union functionality before difference because you need to have first constructed an object before you remove anything from it. Don’t almost all modules have the…

difference() {
        union() {
                // add some stuff
        }
        // take some stuff away
}

construct in them?

So that’s why I was thinking that a syntax that supported what I have at least found to be the most common code construction would make code more readable, so that I would just write:

module foo() {

        union : {
                // code that primarily builds the object
        }
        diff : {
                // code that primarily subtracts geometry from union()
        }

        // code that follows executes only if foo is called
}

Now when I want the foo object to be combined with other objects, I would just have to write:

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Perhaps there may be a more elegant way of structuring things, but I was aiming at a syntax that while not backwards compatible, wouldn’t break anything that was already working.

Thanks for the heads up on the availability of function literals… that should make life more fun and exciting. And thanks for the links to the discussion lists.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

nophead
Well I consider my way of working more object oriented. A class normally has lots of different methods named Class::method and with an implicit this pointer or self reference. I just do this explicitly with class_method(type).

I don't see any connection between adding and subtracting objects with constructors and destructors. The latter are about object lifetime and there is no such concept in OpenSCAD because it is a static description.

I also don't see your point about a proliferation of modules. I think of a used OpenSCAD file as a class and the modules and functions as methods. You seem to be treating a module as a class and trying to access things inside of it. I consider the internals of my modules private and expose and interface to my objects with functions.

On Mon, 28 Oct 2019 at 09:43, Hugo Jackson <[hidden email]> wrote:


On Oct 28, 2019, at 1:51 AM, nop head <[hidden email]> wrote:

Instead of 

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Why don't you simply define two modules foo_union() and foo_diff()? 

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.

In my case I would have foo(type), foo_holes(type) where type is a list with all the parameters and I have accessor functions such as foo_width(type).

If there is common positioning between foo() and foo_holes() then I would have foo_hole_positions(type) that positions children().

I take your point, and the distributed functionality of the modules you recommend is something I have tried and eventually abandoned… I think I just found the proliferation of modules a little unsatisfying.

I think my current direction is shaped by my experience with object oriented programming… indeed, in OpenSCAD I’m primarily creating actual objects :)

So to my way of thinking, and I’d be the first to concede that I may not have the experience to really warrant an opinion, some adoption of object oriented philosophy would improve the OpenSCAD programming experience even if its not an object oriented language.

So while in a conventional imperative language it may be insane to combine two bits of code whose execution is selected by a passed parameter, what I’m trying to do is get at least some feel for a more oo like environment even though the language doesn’t support it, and my proposal to do that is part of that goal, and that’s the reason for my proposal of extended dot notation… the ability to call the ‘methods’ of OpenSCAD objects seems natural to me.

The second part of the proposal whether it’s accomplished with labels or ‘reserved’ methods is just my attempt to suggest something that might feel something like the constructor/destructor functions of an oo object. With ‘real’ objects like in OpenSCAD I liken the union method to a constructor and the difference/intersection functionality to a destructor and my proposal was aimed at incorporating the benefits of that kind of structure to an OpenSCAD program.

Anyway, thanks for you feedback, it's helping me to develop a better understanding of what I’m wishing for, even if that desire is unrealistic, impractical or unachievable.



On Mon, 28 Oct 2019 at 04:25, Hugo Jackson <[hidden email]> wrote:


> On Oct 27, 2019, at 5:13 PM, Torsten Paul <[hidden email]> wrote:
>
> First note that the function literals are now
> implemented, so the snapshot version of OpenSCAD
> has functions as first class values which means
> support for higher order functions.
> (https://github.com/openscad/openscad/pull/3077)
>
> I hope to find some time to collect notes and post
> an article about it. Meanwhile the minimalist docu
> can be found at
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals
>
> On 28.10.19 00:09, Hugo Jackson wrote:
>> To start, I would propose an extension of the "dot"
>> notation, that would allow one to refer to a value
>> declaration and/or function or module component of
>> another module with a dot.
>
> Yes, having access to a nested data structure is
> definitely something that would help a lot. The
> core changes to the parser implementation that are
> required for this are now done and merged to the
> development snapshot.
>
> But I don't think it will be possible to link to
> the existing function and/or module definitions.
>
> Slightly modified example, just adding a parameter
> to module foo():
>
> module foo(offset) {
>       valueA = 7 + offset;
>
>       function myFunc(num) = valueA + num;
> }
>
> module bar() {
>       valueB = 8;
>
>       valueC = foo.valueA + foo.myFunc(valueB);
> }
>
> foo(10);
> translate([10, 10, 0]) foo(20);
>
> bar(); // <- now what is valueC ?
>

Good point… for my part I don’t usually code modules with parameters, but I appreciate that isn’t how the real world works. :)
But I would think that calling any module part or function would require an enumeration of all needed values in the parameter arguments, e.g. for the example you
provide the call for valueC in bar would need to be:

valueC = foo(offset = 7).valueA + foo(offset = 7).myFunc(valueB) … or literally valueC = foo(7).valueA + foot(7).myFunc(valueB)

Perhaps that would lead to a preponderance of code that would only serve to make code look more tortuous than it already does. Yet I think the
proposed ‘dot’ syntax would lead to more insightful coding that would tend to mitigate the damage that might occur.

>
>> The second extension would be the election of three
>> operations as 'reserved' functions, union, difference
>> and intersection such that one could explicitly call
>> that part of a module without calling the others:
>
> I'm not sure I understand how this will work. Why
> select specifically those 3 special cases?
>
> Is that meant just as names or would that also mean
> intersection() { bar(); foo(); } a bit like operator
> overloading?
>
>> foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
>
> Where's the nesting coming from? From the order of
> the definitions?
>
>> Please let me know… I didn’t want to bog this
>> proposal down with details if it’s obvious, but in
>> doing that I have taken the risk that the improvement
>> And benefits of such extensions may not be evident.



I often code modules using a special varialble I name $e and a skeleton module that looks like this:

module foo($e = -1) {
        module _union() {
                // code that primarily builds the object
        }

        module _diff() {
                // code that primarily subtracts geometry from _union()
        }

        difference() {
                if($e == -1 || $e == 0)
                        _union();
                if($e == -1 || $e == 1)
                        _diff();
        }               
}

I then get to call foo and either get just the _union code or just the _diff code or have the object definition run completely when $e == -1

With this approach, when I just want the foo object I simply write:

foo();

But if I want the foo object to be united with some other objects before any difference is applied I could do it like this:

module bar() {
        difference() {
                union() {
                        foo($e = 0);
                        cylinder(d = 5, h = 10);
                }
                foo($e = 1);
        }
}

I find that this kind of approach helps with the overall flow and data abstraction, but the addition of a special variable and the requirement for the difference(){union() {}} code to make it work detracts from what I feel is overall a more elegant approach, and I find it particularly helpful for code reuse.
So that’s really what my suggestion for ’reserved’ functions is about.. following the logic that you would execute union functionality before difference because you need to have first constructed an object before you remove anything from it. Don’t almost all modules have the…

difference() {
        union() {
                // add some stuff
        }
        // take some stuff away
}

construct in them?

So that’s why I was thinking that a syntax that supported what I have at least found to be the most common code construction would make code more readable, so that I would just write:

module foo() {

        union : {
                // code that primarily builds the object
        }
        diff : {
                // code that primarily subtracts geometry from union()
        }

        // code that follows executes only if foo is called
}

Now when I want the foo object to be combined with other objects, I would just have to write:

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Perhaps there may be a more elegant way of structuring things, but I was aiming at a syntax that while not backwards compatible, wouldn’t break anything that was already working.

Thanks for the heads up on the availability of function literals… that should make life more fun and exciting. And thanks for the links to the discussion lists.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

acwest
I know that in my library, I created a draw module, with a large number of arguments to control how it rendered the children. It was a wrapper around what was essentially a large switch case, so you could control things like the % operator with boolean flags,as well as things like colour and alpha. The code is terrible from a programmers point of view, but it makes it much easier to turn on and off multiple sections of the display by only editing a few variables. Most of my designs were intended for the thingiverse customiser, so this method of working makes a lot of sense 

On Mon, 28 Oct 2019, 07:09 nop head, <[hidden email]> wrote:
Well I consider my way of working more object oriented. A class normally has lots of different methods named Class::method and with an implicit this pointer or self reference. I just do this explicitly with class_method(type).

I don't see any connection between adding and subtracting objects with constructors and destructors. The latter are about object lifetime and there is no such concept in OpenSCAD because it is a static description.

I also don't see your point about a proliferation of modules. I think of a used OpenSCAD file as a class and the modules and functions as methods. You seem to be treating a module as a class and trying to access things inside of it. I consider the internals of my modules private and expose and interface to my objects with functions.

On Mon, 28 Oct 2019 at 09:43, Hugo Jackson <[hidden email]> wrote:


On Oct 28, 2019, at 1:51 AM, nop head <[hidden email]> wrote:

Instead of 

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Why don't you simply define two modules foo_union() and foo_diff()? 

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.

In my case I would have foo(type), foo_holes(type) where type is a list with all the parameters and I have accessor functions such as foo_width(type).

If there is common positioning between foo() and foo_holes() then I would have foo_hole_positions(type) that positions children().

I take your point, and the distributed functionality of the modules you recommend is something I have tried and eventually abandoned… I think I just found the proliferation of modules a little unsatisfying.

I think my current direction is shaped by my experience with object oriented programming… indeed, in OpenSCAD I’m primarily creating actual objects :)

So to my way of thinking, and I’d be the first to concede that I may not have the experience to really warrant an opinion, some adoption of object oriented philosophy would improve the OpenSCAD programming experience even if its not an object oriented language.

So while in a conventional imperative language it may be insane to combine two bits of code whose execution is selected by a passed parameter, what I’m trying to do is get at least some feel for a more oo like environment even though the language doesn’t support it, and my proposal to do that is part of that goal, and that’s the reason for my proposal of extended dot notation… the ability to call the ‘methods’ of OpenSCAD objects seems natural to me.

The second part of the proposal whether it’s accomplished with labels or ‘reserved’ methods is just my attempt to suggest something that might feel something like the constructor/destructor functions of an oo object. With ‘real’ objects like in OpenSCAD I liken the union method to a constructor and the difference/intersection functionality to a destructor and my proposal was aimed at incorporating the benefits of that kind of structure to an OpenSCAD program.

Anyway, thanks for you feedback, it's helping me to develop a better understanding of what I’m wishing for, even if that desire is unrealistic, impractical or unachievable.



On Mon, 28 Oct 2019 at 04:25, Hugo Jackson <[hidden email]> wrote:


> On Oct 27, 2019, at 5:13 PM, Torsten Paul <[hidden email]> wrote:
>
> First note that the function literals are now
> implemented, so the snapshot version of OpenSCAD
> has functions as first class values which means
> support for higher order functions.
> (https://github.com/openscad/openscad/pull/3077)
>
> I hope to find some time to collect notes and post
> an article about it. Meanwhile the minimalist docu
> can be found at
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules#Function_Literals
>
> On 28.10.19 00:09, Hugo Jackson wrote:
>> To start, I would propose an extension of the "dot"
>> notation, that would allow one to refer to a value
>> declaration and/or function or module component of
>> another module with a dot.
>
> Yes, having access to a nested data structure is
> definitely something that would help a lot. The
> core changes to the parser implementation that are
> required for this are now done and merged to the
> development snapshot.
>
> But I don't think it will be possible to link to
> the existing function and/or module definitions.
>
> Slightly modified example, just adding a parameter
> to module foo():
>
> module foo(offset) {
>       valueA = 7 + offset;
>
>       function myFunc(num) = valueA + num;
> }
>
> module bar() {
>       valueB = 8;
>
>       valueC = foo.valueA + foo.myFunc(valueB);
> }
>
> foo(10);
> translate([10, 10, 0]) foo(20);
>
> bar(); // <- now what is valueC ?
>

Good point… for my part I don’t usually code modules with parameters, but I appreciate that isn’t how the real world works. :)
But I would think that calling any module part or function would require an enumeration of all needed values in the parameter arguments, e.g. for the example you
provide the call for valueC in bar would need to be:

valueC = foo(offset = 7).valueA + foo(offset = 7).myFunc(valueB) … or literally valueC = foo(7).valueA + foot(7).myFunc(valueB)

Perhaps that would lead to a preponderance of code that would only serve to make code look more tortuous than it already does. Yet I think the
proposed ‘dot’ syntax would lead to more insightful coding that would tend to mitigate the damage that might occur.

>
>> The second extension would be the election of three
>> operations as 'reserved' functions, union, difference
>> and intersection such that one could explicitly call
>> that part of a module without calling the others:
>
> I'm not sure I understand how this will work. Why
> select specifically those 3 special cases?
>
> Is that meant just as names or would that also mean
> intersection() { bar(); foo(); } a bit like operator
> overloading?
>
>> foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
>
> Where's the nesting coming from? From the order of
> the definitions?
>
>> Please let me know… I didn’t want to bog this
>> proposal down with details if it’s obvious, but in
>> doing that I have taken the risk that the improvement
>> And benefits of such extensions may not be evident.



I often code modules using a special varialble I name $e and a skeleton module that looks like this:

module foo($e = -1) {
        module _union() {
                // code that primarily builds the object
        }

        module _diff() {
                // code that primarily subtracts geometry from _union()
        }

        difference() {
                if($e == -1 || $e == 0)
                        _union();
                if($e == -1 || $e == 1)
                        _diff();
        }               
}

I then get to call foo and either get just the _union code or just the _diff code or have the object definition run completely when $e == -1

With this approach, when I just want the foo object I simply write:

foo();

But if I want the foo object to be united with some other objects before any difference is applied I could do it like this:

module bar() {
        difference() {
                union() {
                        foo($e = 0);
                        cylinder(d = 5, h = 10);
                }
                foo($e = 1);
        }
}

I find that this kind of approach helps with the overall flow and data abstraction, but the addition of a special variable and the requirement for the difference(){union() {}} code to make it work detracts from what I feel is overall a more elegant approach, and I find it particularly helpful for code reuse.
So that’s really what my suggestion for ’reserved’ functions is about.. following the logic that you would execute union functionality before difference because you need to have first constructed an object before you remove anything from it. Don’t almost all modules have the…

difference() {
        union() {
                // add some stuff
        }
        // take some stuff away
}

construct in them?

So that’s why I was thinking that a syntax that supported what I have at least found to be the most common code construction would make code more readable, so that I would just write:

module foo() {

        union : {
                // code that primarily builds the object
        }
        diff : {
                // code that primarily subtracts geometry from union()
        }

        // code that follows executes only if foo is called
}

Now when I want the foo object to be combined with other objects, I would just have to write:

module bar() {
        union : {
                foo.union();
                _cylinder(d = 5, h = 10);
        }
        diff : {
                foo.diff();
        }
}

Perhaps there may be a more elegant way of structuring things, but I was aiming at a syntax that while not backwards compatible, wouldn’t break anything that was already working.

Thanks for the heads up on the availability of function literals… that should make life more fun and exciting. And thanks for the links to the discussion lists.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

tp3
In reply to this post by boxcarmib
On 28.10.19 05:24, Hugo Jackson wrote:
> valueC = foo(offset = 7).valueA + foo(offset = 7).myFunc(valueB) …
> or literally valueC = foo(7).valueA + foot(7).myFunc(valueB)
>
> Perhaps that would lead to a preponderance of code that would
> only serve to make code look more tortuous than it already does.
> Yet I think the proposed ‘dot’ syntax would lead to more
> insightful coding that would tend to mitigate the damage that
> might occur.

I guess that would make it also impossible to change, so
that's not a good solution.

That does not mean the 'dot' syntax can't be used though.
It simply means we need to find a way to access the
instantiated modules and functions, not the declaration.

The incomplete/proposed object literals would allow that
this way with functions:

o = {
    var = 3;
    func = function(x) x + var;
};

Now we have a nested structure named o which has both a
variable 'var' and a function 'func'.

Accessing both can go via the common 'dot' notation:

echo(o.var); // ECHO: 3
echo(o.func(5)); // ECHO: 8

and that works just as expected when passing this thing
called 'o' to a module:

module mod(thing) {
    echo(thing.var);
    echo(thing.func(1));
}

mod(o);

The current struggle is how to fit modules and therefor
the geometry generation into that design.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

tp3
In reply to this post by nophead
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

nophead
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for extensions to the OpenSCAD syntax

tp3
On 28.10.19 19:11, nop head wrote:
> Why do you need to automatic select between drawing
> an object and making a hole for it?

To give all those people asking for it a solution
that works? I don't know if it's possible but if it
is, I think that would help people who just want
to combine a couple of modules from a library they
did not write themselves.

> To me they are completely separate operations and
> I am quite happy to code two separate modules and
> call them from different places.

That's fine, nobody is going to take that away. But
please consider there's a large number of users who
have quite different use cases, specifically much
simpler ones. If we can make the life of those users
easier, that's a good thing.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
12