You need to understand the concepts of lexical scope and dynamic scope. To
get something that is global you need to define it at the top level scope.
I.e. file level, outside of any functions, modules. If you assign to it
again at in the same scope it will use the last value assigned everywhere.
If you assign to it in a deeper scope it will simply define a new constant
that hides the original.

A normal variable defined at file scope is visible everywhere later in that
file, but not in modules and functions in other files, called from that
file. They have lexical scope meaning you can see where they are visible
simply by looking at the static program structure. Each module, function
and block enclosed by braces is a new scope. Inside that scope you can
access names defined in scopes that enclose it.

The only difference with $ prefixed  names is they have dynamic scope
meaning they are visible not only in the lexical scope they are defined in
but also in any modules or functions called from that scope, even if they
are in different files. But again if you define a new one in a deeper scope
it hides the original. It doesn't reassign the original. And constants
defined in a deeper scope disappear when that scope ends. They never leak
from an inner scope to an outer one.
On Nov 15, 2015 1:54 AM, "whburling" whburling@outlook.com wrote:

The real problem with 'use' is that it doesn't import variable definitions,
only function and module definitions.

On 15 November 2015 at 13:26, L Boyd lboyd@frontiernet.net wrote:

That is a pro, not a con. Better encapsulation.
On Nov 15, 2015 7:25 PM, "doug moen" doug@moens.org wrote:

It's definitely a feature. I'm in the habit of coding my utility and library scad files to "self test" when rendered directly or via include, and "use" them across project and variant boundaries. If they depend on top-level variable values then they need rework to be more portable.

Anything that needs to be treated like a global reference or design value shareable across multiple projects, I code as a 0-argument function.

function pi() =3.141592;

It also allowed you do things like incorporate tolerances, design-for-manufacturing rules (min spacing, wall thickness, etc) as arguments to the function-definitions.

Andrew

Sent from myBrain

I have difficulty understanding how the current design of 'use' is a "pro",
and I'm skeptical about the claim that it supports "better encapsulation".

If we really want to support better encapsulation in libraries, then we
should provide a way for libraries to control which functions, modules and
variables are exported, and which are private. I'd be happy with something
as simple as a naming convention: names beginning with _ or $ are private.

My current hatred of 'use' comes from my struggles to figure out how to use
the MCAD library. This is the standard library that ships with OpenSCAD.

You can import these files in your scripts with `use

<MCAD/filename.scad>`,
where 'filename' is one of the files listed below like 'motors' or
'servos'.

This implies that the purpose of 'use' is for importing a library file, but
it's all a big lie.

In order to successfully use an MCAD library file, you must first read the
file, reverse engineer it, and determine whether the author intended it to
be referenced via 'use' or 'include'. Some library files work only with
'use', some work only with 'include'.

• Some MCAD scripts export mathematical constants as part of their API.
  You must use include. Examples are math.scad and materials.scad.
• Some MCAD scripts define mathematical constants that are used locally
  within their functions and modules. They won't work with use, you must
  use include. Examples are lego_compatibiity.scad, involute_gears.scad.
• Some MCAD scripts have top level geometry as example code. They are
  designed to work with use. For example, trochoids.scad contains demo
  code with top level geometry and parameter definitions, including a
  definition of $fn. These parameter definitions are intended to be
  invisible when the script is used.

https://github.com/doug-moen/openscad2/blob/master/rfc/Library_Scripts.md#referencing-a-model-script

On 15 November 2015 at 17:38, nop head nop.head@gmail.com wrote:

I suspect library modules should be implemented as two files, one that you
include to get constants and one that you use to get functions and modules.

Note that even if you use a module you can still override constants in it
by passing them as extra parameters.
On Nov 15, 2015 11:52 PM, "doug moen" doug@moens.org wrote:

nophead wrote

Decided to test this using my example posted earlier.

part of Global Test.scad

module Test1(){
cube(4);
echo(" in Test1  x1 = ",x1);
echo(" in Test1 $y1 = ",$y1);
}
x1 = 3;
$y1 = 5;

Local file

use<Global Test.scad>;

Test1();
ECHO: " in Test1  x1 = ", 3
ECHO: " in Test1 $y1 = ", 5

Test1(x1=19);
ECHO: " in Test1  x1 = ", 19
ECHO: " in Test1 $y1 = ", 5

Test1(x1=192,$y1=157);
ECHO: " in Test1  x1 = ", 192
ECHO: " in Test1 $y1 = ", 157

Test1();                      // after all of the above
ECHO: " in Test1  x1 = ", 3
ECHO: " in Test1 $y1 = ", 5

I was able to temporarily override the internal values of x1 and $y1 even
thought they did not appear as parameters in the definition of Test1()!

--
View this message in context: http://forum.openscad.org/Special-Variables-tp14477p14538.html
Sent from the OpenSCAD mailing list archive at Nabble.com.