For me, the differance between use and include, its that if using an
include I have to comment out 'test code' in the file that I am
including.  No big deal.

On 24/10/2021 21:57, Jordan Brown wrote:

On 10/24/2021 1:47 PM, Ray West wrote:

On 24/10/2021 15:15, Jordan Brown wrote:

A "use" in the middle of a module might in theory be meaningful, but is
not allowed.

Hi Jordan, thanks for the explanation, it is a bug then 😉  .

Eh, shrug.  It's one of those things that could reasonably be designed
either way.  It was designed the way that it was.  That's not a bug, it's
just the way it is.

For me, the differance between use and include, its that if using an
include I have to comment out 'test code' in the file that I am including.
No big deal.

The differences that I can think of are:

- A "used" file doesn't create any geometry (which means that you can
have test/demo stuff in it that doesn't affect its use as a library)
- File-level variables set in a "used" file are not visible to the
caller (which can be good, hiding implementation details, or bad, making it
so that you can't export constants).
- With "use" Modules and functions are visible only to the file that
did the "use".  That is, if A uses B and B uses C, A can't see C's
functions and modules.  This can help hide implementation details.
- Top-level variables in "include" files are evaluated once, at
"include" time, just like the variables in the file that does the include.
Top-level variables in "use" files are evaluated on every call into the
"used" file.  It is controversial whether this is a bug or a feature.
- Because "include" does not participate in the syntax, it can be used
for things like including the body of a table, without including the
framing assignment, [ ]s, et cetera.

I guess that first there was include - it is pretty common in most
compilers that I know of, and then someone thought, for development, nice
to be able to use just the modules, without having to break apart the
original library. Use is handy for development, since you can hop between
files easily,  well, * I* know what I'm getting at.  I have a 'feeling'
that once it is proven, make it into a library that will be included makes
it the same as copy and paste the whole file, as always.

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

When you use a file it is only parsed once, no matter how many times
it is used in a project, and then kept in a cache. Include files are
parsed whenever they are encountered.

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
  [
    ["height",  height ],
    ["width",   width  ],
    ["length",  length ],
  ];

function stepper_motor_bracket( name ) =
  let ( row = search( [name], constants )[0] )
  row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
  cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not
the way I have been doing this sort of thing. If talking about stepper
motors, then I would have one library file with a module for details
of each type that I was interested in, nema 23, nema17, nema 32,
whatever. The mountiong plate details are not related to the numbers
17, 23/whatever, nor the shaft diameter. so it would be a few number
of modules in one file. (with common variables sd, pd, pl, for shaft
diameter, pilot diameter, pilot length etc.) I'd leave in the test
code (but comment it). Mounting plate dimensions would be derived from
the motor details, wrt fixing hole positions pilot diameter, etc. each
module  would draw the object, and could echo dimensions if needed.
For the plate, it would probably be the motor fixing holes and pilot
and shaft clearance details - as cylinders, to be differenced from a
plate defined by length, width, thickness, and its fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values.
for location, etc. for the specific library motor plate module. Most
of the values would be static, within the stepper motor library module
e.g. motor bolt hole details, so it would be just the size of plate,
its location and  its fixing holes I'd need to set. If every plate for
the different motors i was using had a common thickness, then that
could be defined outside of the modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to
do this for my own use, and next week, I'll be onto something else, so
no need for it to look pretty, so to speak, nobody else needs to use
it. If it were just one or two motor plates, say, then I could have a
file for each plate and use it or include it as needed, but I would
most likely need nothing more than this.  (I'm half inclined to test
out what I'm trying to explain...)

Best wishes,

Ray

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
[
["height",  height ],
["width",  width  ],
["length",  length ],
];

function stepper_motor_bracket( name ) =
let ( row = search( [name], constants )[0] )
row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not the
way I have been doing this sort of thing. If talking about stepper motors,
then I would have one library file with a module for details of each type
that I was interested in, nema 23, nema17, nema 32, whatever. The mountiong
plate details are not related to the numbers 17, 23/whatever, nor the shaft
diameter. so it would be a few number of modules in one file. (with common
variables sd, pd, pl, for shaft diameter, pilot diameter, pilot length
etc.) I'd leave in the test code (but comment it). Mounting plate
dimensions would be derived from the motor details, wrt fixing hole
positions pilot diameter, etc. each module  would draw the object, and
could echo dimensions if needed. For the plate, it would probably be the
motor fixing holes and pilot and shaft clearance details - as cylinders, to
be differenced from a plate defined by length, width, thickness, and its
fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values. for
location, etc. for the specific library motor plate module. Most of the
values would be static, within the stepper motor library module e.g. motor
bolt hole details, so it would be just the size of plate, its location and
its fixing holes I'd need to set. If every plate for the different motors i
was using had a common thickness, then that could be defined outside of the
modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to do
this for my own use, and next week, I'll be onto something else, so no need
for it to look pretty, so to speak, nobody else needs to use it. If it were
just one or two motor plates, say, then I could have a file for each plate
and use it or include it as needed, but I would most likely need nothing
more than this.  (I'm half inclined to test out what I'm trying to
explain...)

Best wishes,
Ray

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org