Suggestion: If behaviour

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

Suggestion: If behaviour

Troberg
As it works today, it's not possible to do stuff like this:

    if(colorit){
        color([...])
    }
    sphere(10);

This is a simple canse, but often, you want to have one/several conditional
step in a large pile of operations, more code than I'd like to duplicate.

So, I usually have to resort to something like this instead:

    module ifcolor(condition,color){
        if(condition){
            color(color)
            children();
        }else{
            children();
        }
    }

    ifcolor(colorit,[...])
    sphere(10);

While it works, I find myself ending up with many if* variants which make
very little sense outside that context.

So, what I'd like is either to have the if working as one might expect it to
work in the first example, of have some more generic module that mimics what
I do in my module, which takes as an argument the operations to do.

Since it doesn't work at all today, it wouldn't, as far as I can see, break
any existing code.

It would make a lot of code much, much cleaner.



--
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: Suggestion: If behaviour

nophead
I use nested modules instead of creating lots of helper modules.

E.g.
module thing() {
   module theThing() {
      ....
   }
   if(condition)
        color("grey") theThing();
   else
       theThing();
}

On Tue, 4 Feb 2020 at 10:00, Troberg <[hidden email]> wrote:
As it works today, it's not possible to do stuff like this:

    if(colorit){
        color([...])
    }
    sphere(10);

This is a simple canse, but often, you want to have one/several conditional
step in a large pile of operations, more code than I'd like to duplicate.

So, I usually have to resort to something like this instead:

    module ifcolor(condition,color){
        if(condition){
            color(color)
            children();
        }else{
            children();
        }
    }

    ifcolor(colorit,[...])
    sphere(10);

While it works, I find myself ending up with many if* variants which make
very little sense outside that context.

So, what I'd like is either to have the if working as one might expect it to
work in the first example, of have some more generic module that mimics what
I do in my module, which takes as an argument the operations to do.

Since it doesn't work at all today, it wouldn't, as far as I can see, break
any existing code.

It would make a lot of code much, much cleaner.



--
Sent from: http://forum.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: Suggestion: If behaviour

Troberg
nophead wrote
> I use nested modules instead of creating lots of helper modules.

So do I, but I left it out of the example for clarity. Still, it's not the
neatest imaginable solution...




--
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: Suggestion: If behaviour

DonGar
If a model could be assigned to a variable, this would be more like traditional languages.

thing = theThing();

if (condition)
   thing = color("grey") thing;

On Tue, Feb 4, 2020 at 2:27 AM Troberg <[hidden email]> wrote:
nophead wrote
> I use nested modules instead of creating lots of helper modules.

So do I, but I left it out of the example for clarity. Still, it's not the
neatest imaginable solution...




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

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


--
Don

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

Re: Suggestion: If behaviour

Whosawhatsis
In reply to this post by Troberg
There have been plenty of times I've wanted to do things like this too. There are often ways around it. With the current features, you can't conditionally color something or leave it un-colored, but you can set the color conditionally by using a ternary operator like this:

color(condition ? [.2, .3, .4] : "grey") {
sphere(10);
}

I'd really like to be able to do this with the ! * # % operators, but there's definitely no way to do that without duplicating code currently. The closes you can get would be putting the code that would otherwise be duplicated in a module, so that only the module call needs to appear on both sides of the "else".

On February 4, 2020 at 02:00:36, Troberg ([hidden email]) wrote:

As it works today, it's not possible to do stuff like this:

if(colorit){
color([...])
}
sphere(10);

This is a simple canse, but often, you want to have one/several conditional
step in a large pile of operations, more code than I'd like to duplicate.

So, I usually have to resort to something like this instead:

module ifcolor(condition,color){
if(condition){
color(color)
children();
}else{
children();
}
}

ifcolor(colorit,[...])
sphere(10);

While it works, I find myself ending up with many if* variants which make
very little sense outside that context.

So, what I'd like is either to have the if working as one might expect it to
work in the first example, of have some more generic module that mimics what
I do in my module, which takes as an argument the operations to do.

Since it doesn't work at all today, it wouldn't, as far as I can see, break
any existing code.

It would make a lot of code much, much cleaner.



--
Sent from: http://forum.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: Suggestion: If behaviour

Troberg
You can, but don't get stuck on color. I just used that for a clean example.
It could just as well be the other operations, or several of them.

If course, you can also do algebraic ifs for translate/rotate, but it's
really not good, readable code.

There are heaps of workarounds, but none of them are really what I would
consider "good coding practice".



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

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