On 11/11/2024 10:29 AM, Todd Allen via Discuss wrote:
But if the word geometry is technically reserved for something else
such as the output of rendering then thanks for the correction and
explanation.
I don't think there's a clear nomenclature that distinguishes between
"data values that represent a shape" and "the result of OpenSCAD
model-creation operations".
I do think that we need to adopt some nomenclature there, for two
reasons, both tied to my PR#4478 but applicable to similar proposals.
First, as we introduce what JavaScript calls objects and Python calls
dictionaries, the word "object" becomes ambiguous: does it refer to a
name-value data structure (perhaps eventually with other OO behaviors),
or to a geometric shape?
Second, PR#4478 introduces a mechanism for taking a piece of an OpenSCAD
model and treating it as a data value - you can put it into a variable,
pass it to a module or function, return it from a function, et cetera.
(For the curious: internally, it's a CSG tree.) What do we call that
data type? To make things trickier, there's a render() function that
takes that opaque value and returns a conventional array / name-value
data structure that is the result of rendering it - metadata plus for a
list of points plus for 2D object a list of paths and for 3D objects a
list of faces. (For BOSL2 fans, it's basically the same as a VNF.)
What do we call that?
I like "object" for the data structure, by way of analogy to "objects"
in other languages, especially when and if we gain additional
object-like behavior. "dictionary" has some appeal, based on Python,
but in Python objects and dictionaries are different animals. In
JavaScript, on the other hand, there are only objects.
I've been trying to use "geometry" or "shape" to refer to the OpenSCAD
part-of-the-model construct and its associated data type.
But my opinion is not the authoritative answer.
On 11/11/2024 10:29 AM, Todd Allen via Discuss wrote:
> But if the word geometry is technically reserved for something else
> such as the output of rendering then thanks for the correction and
> explanation.
I don't think there's a clear nomenclature that distinguishes between
"data values that represent a shape" and "the result of OpenSCAD
model-creation operations".
I *do* think that we need to adopt some nomenclature there, for two
reasons, both tied to my PR#4478 but applicable to similar proposals.
First, as we introduce what JavaScript calls objects and Python calls
dictionaries, the word "object" becomes ambiguous: does it refer to a
name-value data structure (perhaps eventually with other OO behaviors),
or to a geometric shape?
Second, PR#4478 introduces a mechanism for taking a piece of an OpenSCAD
model and treating it as a data value - you can put it into a variable,
pass it to a module or function, return it from a function, et cetera.
(For the curious: internally, it's a CSG tree.) What do we call that
data type? To make things trickier, there's a render() function that
takes that opaque value and returns a conventional array / name-value
data structure that is the result of rendering it - metadata plus for a
list of points plus for 2D object a list of paths and for 3D objects a
list of faces. (For BOSL2 fans, it's basically the same as a VNF.)
What do we call *that*?
I like "object" for the data structure, by way of analogy to "objects"
in other languages, especially when and if we gain additional
object-like behavior. "dictionary" has some appeal, based on Python,
but in Python objects and dictionaries are different animals. In
JavaScript, on the other hand, there are only objects.
I've been trying to use "geometry" or "shape" to refer to the OpenSCAD
part-of-the-model construct and its associated data type.
But my opinion is not the authoritative answer.
