Empathy List Archives

PC

Patrick Callahan

Mon, Nov 22, 2021 3:19 PM

I am building assemblies with several parts, each of which has numerous and
sometimes complex features.

I found several ideas for organizing a large number of individual
measurements and wondered if there might be other approaches or if
contemplated changes to OpenSCAD itself might also be helpful.

First, organize the data in one file and geometry in a second file.
Second, organize the data in columns form, using vectors as containers,
labeling the columns of data in comments.
Third, include a name and description in the vector.
Fourth, when using the vector, provide accessor functions for the
individual columns.

I have an additional idea I'm using in my work. Constructors. I found it
easy to identify features but more challenging to organize that information
into comprehensible tables.

I'm calling a constructor function instead of simply specifying the values
of a vector, so I can label each measurement with a name without using a
table.
The constructor functions assemble the named parameters into a vector, and
accessor functions provide the values by name.

I'm still assessing whether a formal constructor is a good idea. I'm
considering whether to apply the concept everywhere or to simply use it
when deemed "necessary".

I am building assemblies with several parts, each of which has numerous and sometimes complex features. I found several ideas for organizing a large number of individual measurements and wondered if there might be other approaches or if contemplated changes to OpenSCAD itself might also be helpful. First, organize the data in one file and geometry in a second file. Second, organize the data in columns form, using vectors as containers, labeling the columns of data in comments. Third, include a name and description in the vector. Fourth, when using the vector, provide accessor functions for the individual columns. I have an additional idea I'm using in my work. Constructors. I found it easy to identify features but more challenging to organize that information into comprehensible tables. I'm calling a constructor function instead of simply specifying the values of a vector, so I can label each measurement with a name without using a table. The constructor functions assemble the named parameters into a vector, and accessor functions provide the values by name. I'm still assessing whether a formal constructor is a good idea. I'm considering whether to apply the concept everywhere or to simply use it when deemed "necessary".

NH

nop head

Mon, Nov 22, 2021 3:29 PM

My library: NopSCADlib, works exactly like you describe. All my objects are
described by lists of properties that are accessed through accessor
functions. I also have constructor functions to make any lists that are
expected to be provided by clients of the library, e.g. for customisable
printed parts. The lists that represent fixed vitamins are defined by lists
in the library and don't have constructors.

On Mon, 22 Nov 2021 at 15:19, Patrick Callahan pat.callahan1@gmail.com
wrote:

I am building assemblies with several parts, each of which has numerous
and sometimes complex features.

I found several ideas for organizing a large number of individual
measurements and wondered if there might be other approaches or if
contemplated changes to OpenSCAD itself might also be helpful.

First, organize the data in one file and geometry in a second file.
Second, organize the data in columns form, using vectors as containers,
labeling the columns of data in comments.
Third, include a name and description in the vector.
Fourth, when using the vector, provide accessor functions for the
individual columns.

I have an additional idea I'm using in my work. Constructors. I found it
easy to identify features but more challenging to organize that information
into comprehensible tables.

I'm calling a constructor function instead of simply specifying the values
of a vector, so I can label each measurement with a name without using a
table.
The constructor functions assemble the named parameters into a vector, and
accessor functions provide the values by name.

I'm still assessing whether a formal constructor is a good idea. I'm
considering whether to apply the concept everywhere or to simply use it
when deemed "necessary".

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

My library: NopSCADlib, works exactly like you describe. All my objects are described by lists of properties that are accessed through accessor functions. I also have constructor functions to make any lists that are expected to be provided by clients of the library, e.g. for customisable printed parts. The lists that represent fixed vitamins are defined by lists in the library and don't have constructors. On Mon, 22 Nov 2021 at 15:19, Patrick Callahan <pat.callahan1@gmail.com> wrote: > I am building assemblies with several parts, each of which has numerous > and sometimes complex features. > > I found several ideas for organizing a large number of individual > measurements and wondered if there might be other approaches or if > contemplated changes to OpenSCAD itself might also be helpful. > > First, organize the data in one file and geometry in a second file. > Second, organize the data in columns form, using vectors as containers, > labeling the columns of data in comments. > Third, include a name and description in the vector. > Fourth, when using the vector, provide accessor functions for the > individual columns. > > I have an additional idea I'm using in my work. Constructors. I found it > easy to identify features but more challenging to organize that information > into comprehensible tables. > > I'm calling a constructor function instead of simply specifying the values > of a vector, so I can label each measurement with a name without using a > table. > The constructor functions assemble the named parameters into a vector, and > accessor functions provide the values by name. > > I'm still assessing whether a formal constructor is a good idea. I'm > considering whether to apply the concept everywhere or to simply use it > when deemed "necessary". > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

PC

Patrick Callahan

Mon, Nov 22, 2021 4:55 PM

Your library showcases the techniques I described and is the model for my
own library covering flight simulation parts.

My main question at this point is where to draw the line on using
constructors vs simply listing the data in a vector. As I gain experience,
I'll know better where I'll be drawing the line, but wanted to ask how
others made that choice..
I haven't read your whole library but will take a look at your constructors
for guidance.

-Pat

On Mon, Nov 22, 2021 at 10:30 AM nop head nop.head@gmail.com wrote:

My library: NopSCADlib, works exactly like you describe. All my objects
are described by lists of properties that are accessed through accessor
functions. I also have constructor functions to make any lists that are
expected to be provided by clients of the library, e.g. for customisable
printed parts. The lists that represent fixed vitamins are defined by lists
in the library and don't have constructors.

On Mon, 22 Nov 2021 at 15:19, Patrick Callahan pat.callahan1@gmail.com
wrote:

I am building assemblies with several parts, each of which has numerous
and sometimes complex features.

I found several ideas for organizing a large number of individual
measurements and wondered if there might be other approaches or if
contemplated changes to OpenSCAD itself might also be helpful.

First, organize the data in one file and geometry in a second file.
Second, organize the data in columns form, using vectors as containers,
labeling the columns of data in comments.
Third, include a name and description in the vector.
Fourth, when using the vector, provide accessor functions for the
individual columns.

I have an additional idea I'm using in my work. Constructors. I found it
easy to identify features but more challenging to organize that information
into comprehensible tables.

I'm calling a constructor function instead of simply specifying the
values of a vector, so I can label each measurement with a name without
using a table.
The constructor functions assemble the named parameters into a vector,
and accessor functions provide the values by name.

I'm still assessing whether a formal constructor is a good idea. I'm
considering whether to apply the concept everywhere or to simply use it
when deemed "necessary".

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

Your library showcases the techniques I described and is the model for my own library covering flight simulation parts. My main question at this point is where to draw the line on using constructors vs simply listing the data in a vector. As I gain experience, I'll know better where I'll be drawing the line, but wanted to ask how others made that choice.. I haven't read your whole library but will take a look at your constructors for guidance. -Pat On Mon, Nov 22, 2021 at 10:30 AM nop head <nop.head@gmail.com> wrote: > My library: NopSCADlib, works exactly like you describe. All my objects > are described by lists of properties that are accessed through accessor > functions. I also have constructor functions to make any lists that are > expected to be provided by clients of the library, e.g. for customisable > printed parts. The lists that represent fixed vitamins are defined by lists > in the library and don't have constructors. > > On Mon, 22 Nov 2021 at 15:19, Patrick Callahan <pat.callahan1@gmail.com> > wrote: > >> I am building assemblies with several parts, each of which has numerous >> and sometimes complex features. >> >> I found several ideas for organizing a large number of individual >> measurements and wondered if there might be other approaches or if >> contemplated changes to OpenSCAD itself might also be helpful. >> >> First, organize the data in one file and geometry in a second file. >> Second, organize the data in columns form, using vectors as containers, >> labeling the columns of data in comments. >> Third, include a name and description in the vector. >> Fourth, when using the vector, provide accessor functions for the >> individual columns. >> >> I have an additional idea I'm using in my work. Constructors. I found it >> easy to identify features but more challenging to organize that information >> into comprehensible tables. >> >> I'm calling a constructor function instead of simply specifying the >> values of a vector, so I can label each measurement with a name without >> using a table. >> The constructor functions assemble the named parameters into a vector, >> and accessor functions provide the values by name. >> >> I'm still assessing whether a formal constructor is a good idea. I'm >> considering whether to apply the concept everywhere or to simply use it >> when deemed "necessary". >> >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

JB

Jordan Brown

Mon, Nov 22, 2021 5:12 PM

I wouldn't want to forecast when it'll become available, but there's a
feature on the horizon that might interest you: "objects". These are
what other languages call dictionaries (Python), object (JavaScript), or
HashMaps (Java): a data item containing named data items.

There is limited support in the development snapshots; OpenSCAD-internal
functions can create these and OpenSCAD programs can use the results.

tm = textmetrics("hello");
echo(tm);
echo(tm.position);
echo(tm["size"]);

yields

ECHO: { position = [0.96, -0.1408]; size = [27.8024, 10.208]; ascent
= 10.0672; descent = -0.1408; offset = [0, 0]; advance = [29.3443, 0]; }
ECHO: [0.96, -0.1408]
ECHO: [27.8024, 10.208]

What is not yet available is the ability for OpenSCAD programs to create
these objects.

I wouldn't want to forecast when it'll become available, but there's a feature on the horizon that might interest you: "objects". These are what other languages call dictionaries (Python), object (JavaScript), or HashMaps (Java): a data item containing named data items. There is limited support in the development snapshots; OpenSCAD-internal functions can create these and OpenSCAD programs can use the results. tm = textmetrics("hello"); echo(tm); echo(tm.position); echo(tm["size"]); yields ECHO: { position = [0.96, -0.1408]; size = [27.8024, 10.208]; ascent = 10.0672; descent = -0.1408; offset = [0, 0]; advance = [29.3443, 0]; } ECHO: [0.96, -0.1408] ECHO: [27.8024, 10.208] What is not yet available is the ability for OpenSCAD programs to create these objects.

NH

nop head

Mon, Nov 22, 2021 5:33 PM

Constructors make it easy to define lists in the client code because they
have named parameters and can have defaults that stop the library breaking
if the list format changes.

For vitamins like screws that are all defined in the same file in the
library there isn't much point as they can be arranged in a table with
column headers in comments. If the list format changes it is easy to change
the lists to match, so the client code does not break as it only uses the
lists by name and doesn't care what is in them.

On Mon, 22 Nov 2021 at 16:57, Patrick Callahan pat.callahan1@gmail.com
wrote:

Your library showcases the techniques I described and is the model for my
own library covering flight simulation parts.

My main question at this point is where to draw the line on using
constructors vs simply listing the data in a vector. As I gain experience,
I'll know better where I'll be drawing the line, but wanted to ask how
others made that choice..
I haven't read your whole library but will take a look at your
constructors for guidance.