Re: [OpenSCAD] Plans to change variable behavior ?
Okay, let me explain how it works.
In OpenSCAD2, an object is delimited by {...}. It may contain definitions,
like 'zm = pl-zi;' from your octant module, and it may contain geometry
statements, like 'translate(..) color(..) cube(..)' from your octant
module. Definitions add key-value pairs to the object, while geometry
statements add geometry.
Now lets consider your octant module:
module octant(){
for(zi = [0:pl]){
zm = pl-zi;
z = zm<1 ? 0 : p[zm-1];
h = a[zm];
for(yi = [0:zi]){
ym = zi-yi;
y = ym<1 ? 0 : p[ym-1];
l = a[ym];
for(xi = [0:yi]){
xm = yi-xi;
x = xm<1 ? 0 : p[xm-1];
w = a[xm];
if(!hollow || abs(xm+ym-zi) < thick){
hv1 = (xm+ym)/m*360+(zm%2)*120;
hv = hv1 > 360 ? hv1-360 : hv1;
translate([x, y, z]){
color(hsv2rgb(hv, .3, 1)){
cube([w, l, h], center=false);
};
};
}
}
}
}
}
There are lots of {...} object literals in this module, so the result will
be a nested tree of objects.
L0: the top level object contains a list of objects generated by 'for
(zi=...)'
L1: the objects in L0 each contain 3 fields named zm, z, h, plus the
objects generated by 'for (yi=...)'
L2: the objects in L1 each contain 3 fields named ym, y, l, plus the
objects generated by 'for (xi=...)'
L3: the objects in L2 each contain 3 fields xm, x, w, plus zero or one
objects generated by the if, depending on whether the if condition is false
or true.
L4: the optional object in L3 contains 2 fields, hv1, hv, plus the shape
'translate(..) color(..) cube(..)'.
So if I write
oct = octant();
then 'oct' is a object tree, nested 4 levels deep.
len(oct) is the number of L1 objects in oct
oct[0] is the first L1 object in oct
oct[0].zm is the value of the zm field of oct[0], which is a number
Okay?
On 16 November 2015 at 14:53, rickan openscad_rmk@kandarian.com wrote:
Doug Moen said:
rickan, again:
I would like to suggest that modules return objects which contain the
geometrical object in addition to a user definable, user settable, set
of
key => value pairs, i.e. user definable meta-data the module produces.
It
might make sense that some of the keys would be standard e.g. the key
for
the geometrical object itself, the parameters passed to the call
including
children objects, the coordinate transform matrix of the call, the
color,
etc.; but whether or not that is done, the user should be able to
augment
the set.
That is pretty much how the OpenSCAD2 design already works.
I have not made any attempt to define "standard keys", and in the present
design,
primitive shapes like the ones returned by cube() and sphere() don't have
any keys.
All keys within a geometric object are user defined.
But otherwise, it works as you have described.
Here is the section that describes "geometric objects":
https://github.com/doug-moen/openscad2/blob/master/rfc/Objects.md
It doesn't look that way to me because I only see how parameters are input
to the object, not how the object creates values (meta-data) and stores
them for later use as a result of the module call or object instantiation,
e.g, volume or moment of inertia calculated from the input parameters.
In my code example where the cube() is called inside if{!hollow... if
I were to take that if block and put it in a module or object with all
the required input parameters, I could, in that module, calculate and
store the volume of the cube, it's moment of inertia, and I could store
the color for access and analysis in some other part of my program.
--
View this message in context:
http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p14567.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Okay!
That will work very nicely!
--
View this message in context: http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p14576.html
Sent from the OpenSCAD mailing list archive at Nabble.com.