assigned values aren't accessible by child()

[brad]

I wrote about this to the mailing list, but noone replied. Maybe it will get more attention here.

I tried doing something like this:

module test() {
    assign(variable=1) child();
}

test() cube(variable);

and found that OpenSCAD complained about not knowing what variable is.
Shouldn't variable be known to the child? Otherwise the assign really isn't doing anything.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[kintel]

In your example, the cube is evaluated in the context in which it is instantiated, which doesn't know about the variable.
Of course, at the point in time we actually do this evaluation, we also know about the calling context where variable is assigned, so it might be doable to inherit from this latter context. I won't dare doing this before the release though, but it's worth exploring.

[donbright]

for me this is very confusing.

it seems like you basically have a module with 'side effects', i.e. you pass a variable to some module, and it modifies the variable so that it remains changed, even after the module is done. but i could be wrong, because i am having a hard time understanding what is happening.

[brad]

No, the variable should only be changed in the context of the assign statement.

OpenSCAD already works this way with other transforms, like intersection(). Only things in the context of intersect are intersected. If I change my example to:

module test() {
    intersection() child();
}

test() union() {
    cube(10);
    sphere(5);
}

That returns an intersection of the cube and sphere. I just think "assign" should work the same way.

[brad]

oops, that was a bad example.

how about:

module test() {
    translate([0, 10, 0]) child();
}

test() cube(10);

[donbright]

im confused about cases like this:

module test1() {
assign(variable=1) child();
}

module test2() {
assign(variable=2) test1() child();
}

test2() cube(variable);

[brad]

I think it is clarified if you expand everything. If expanded out, your example would look like this:

assign(variable=2)
    assign(variable=1)
        cube(variable);

when it's written this way I think it's pretty clear what should be done: the final assign statement overrides the value set in the first one

[donbright]

yes, but didn't someone just say on the mailing list that

color(blue)
  color(red)
   sphere()

should produce a blue sphere?

i am sure many people would like the feature as you describe it, but i am afraid it is a bit beyond my grasp.

[donbright]

if they ever implement it, i can definitely help test it.

[brad]

Ahh I see. Yes there are arguments for both sides. On the one hand, we have it the way it is currently implemented (as I most recently illustrated), and on the other hand we have the need to override what has already been done. I suppose whatever decision is made there may come to bear on this as well.

[brad]

Actually the issue of which assign overrides the other is not really related to this issue.
First of all, using muiltple levels of modules with child() like you did doesn't even compile in OpenSCAD
Second, even if it did it should just follow rules used elsewhere in OpenSCAD (at the moment, the rule is for the inner most assign to override the outer ones)

[kintel]

Do any of you have any new thoughts on this? Since I recently refactored some of the context handling, it would make sense to look at this again.

[kintel]

Closing as expected behavior; variables are lexically scoped. For dynamically scoped variables, use $variable