redefining a module()
On 6/10/26 6:07 PM, Jordan Brown via Discuss wrote:
Cory says:
It was added as a quick hack to allow overwriting a variable
definition by passing in new assignment values on the command line.
That explains variable overriding. It doesn't explain module/function
overriding.
IIRC the same implementation affected both, so all side effect.
And my problem isn't overloading per se, it's "last processed is
evaluated as if it was written at the first place the same-named thing
was written" and lack of access to preceding definitions. The
traditional shadowing has far fewer footguns.
Cory
On 6/10/2026 7:47 PM, Adrian Mariano via Discuss wrote:
At least the way we've done it, I don't think new features could
conflict with our override, [...]
Even if, say, OpenSCAD added an "anchor" parameter to cube()?
The editor? flags if a module does not exist, so it 'knows' what modules
are present. It should be relatively easy to flag duplicate modules, it
could print a warning message in the console, not necessarily treating
as an error. It may need treating slightly differently than duplicate
variable names, if 'stopping on first warning'
On 11/06/2026 04:29, Jordan Brown via Discuss wrote:
On 6/10/2026 7:47 PM, Adrian Mariano via Discuss wrote:
At least the way we've done it, I don't think new features could
conflict with our override, [...]
Even if, say, OpenSCAD added an "anchor" parameter to cube()?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Yeah, if OpenSCAD added "anchor" to cube() that would indeed conflict with
the override, but really that would be a much bigger problem than just the
override, since it would create a bunch of confusion between the native
feature and the BOSL2 feature. We'd probably have to redesign the library
API in some significant way.
On Wed, Jun 10, 2026 at 11:29 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 6/10/2026 7:47 PM, Adrian Mariano via Discuss wrote:
At least the way we've done it, I don't think new features could
conflict with our override, [...]
Even if, say, OpenSCAD added an "anchor" parameter to cube()?
Does the editor know what modules are in the included (e.g. BOSL2) files? Or
even in the current active file, for that matter.
Seems like a fair bit of functionality from the parser/interpreter would
have be duplicated in the editor.
-----Original Message-----
From: Raymond West via Discuss discuss@lists.openscad.org
Sent: Thursday, June 11, 2026 4:27 AM
To: Jordan Brown via Discuss discuss@lists.openscad.org
Cc: Raymond West raywest@raywest.com
Subject: [OpenSCAD] Re: redefining a module()
The editor? flags if a module does not exist, so it 'knows' what modules are
present. It should be relatively easy to flag duplicate modules, it could
print a warning message in the console, not necessarily treating as an
error. It may need treating slightly differently than duplicate variable
names, if 'stopping on first warning'
On 11/06/2026 04:29, Jordan Brown via Discuss wrote:
On 6/10/2026 7:47 PM, Adrian Mariano via Discuss wrote:
At least the way we've done it, I don't think new features could
conflict with our override, [...]
Even if, say, OpenSCAD added an "anchor" parameter to cube()?
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
On 6/11/2026 5:02 AM, Adrian Mariano wrote:
Yeah, if OpenSCAD added "anchor" to cube() that would indeed conflict
with the override, but really that would be a much bigger problem than
just the override, since it would create a bunch of confusion between
the native feature and the BOSL2 feature. We'd probably have to
redesign the library API in some significant way.
Right, that's the potential problem with this style, where a library
overrides a builtin to add features. Any one case has a low probability
of ever being a problem, but if people do it more and more, eventually
there will be a problem.
For instance, it would be easy for a library to "address" a longstanding
request that the "center" parameter accept other variations, to position
the shape to the positive, center, or negative side of each axis. But
then if OpenSCAD itself ever addressed that request, and didn't do it in
exactly the same way as the library, it would be ... bad.
This kind of override is really really cool when there doesn't end up
being a collision, for exactly the reason that you did it: it yields a
seamless API. But if there ever is a collision, there will be pain.
No, it's more fundamental than that. If OpenSCAD adds some kind of anchor
feature then we have a basic conceptual conflict between what anchor means
in native OpenScad and what it means in BOSL2. It transcends the override
issue. Without the override you'd have a situation where
cuboid(....anchor=) does one thing and cube(...anchor=...) does another
thing. This is fundamentally confusing and much worse than
cuboid(anchor=...) does something and cube(anchor=...) is an error. The
only fix for this would be for BOSL2 to refactor its API and stop using
anchor= as a parameter throughout the entire library. And we'd have to
consider this change even if we had never done any overrides. The risk is
not created by the override. It's a risk the risk of adding any broad
functionality in a library: OpenSCAD could change in a way that conflicts
with it.
Doing the overrides does not increase our exposure to that risk.
On Thu, Jun 11, 2026 at 11:12 AM Jordan Brown openscad@jordan.maileater.net
wrote:
On 6/11/2026 5:02 AM, Adrian Mariano wrote:
Yeah, if OpenSCAD added "anchor" to cube() that would indeed conflict with
the override, but really that would be a much bigger problem than just the
override, since it would create a bunch of confusion between the native
feature and the BOSL2 feature. We'd probably have to redesign the library
API in some significant way.
Right, that's the potential problem with this style, where a library
overrides a builtin to add features. Any one case has a low probability of
ever being a problem, but if people do it more and more, eventually there
will be a problem.
For instance, it would be easy for a library to "address" a longstanding
request that the "center" parameter accept other variations, to position
the shape to the positive, center, or negative side of each axis. But then
if OpenSCAD itself ever addressed that request, and didn't do it in exactly
the same way as the library, it would be ... bad.
This kind of override is really really cool when there doesn't end up
being a collision, for exactly the reason that you did it: it yields a
seamless API. But if there ever is a collision, there will be pain.
On 6/11/2026 10:42 AM, Adrian Mariano wrote:
No, it's more fundamental than that. If OpenSCAD adds some kind of
anchor feature then we have a basic conceptual conflict between what
anchor means in native OpenScad and what it means in BOSL2. It
transcends the override issue. Without the override you'd have a
situation where cuboid(....anchor=) does one thing and
cube(...anchor=...) does another thing. This is fundamentally
confusing and much worse than cuboid(anchor=...) does something and
cube(anchor=...) is an error. The only fix for this would be for
BOSL2 to refactor its API and stop using anchor= as a parameter
throughout the entire library. And we'd have to consider this change
even if we had never done any overrides. The risk is not created by
the override. It's a risk the risk of adding any broad functionality
in a library: OpenSCAD could change in a way that conflicts with it.
Doing the overrides does not increase our exposure to that risk.
Eh, sort of. Yes, when a library introduces a "broad" feature, a
behavior that it presents as ubiquitous, and OpenSCAD evolves to have a
similar-but-different feature, that's a conflict of sorts, a
disharmony. However, one can still draw a line around the OpenSCAD
components and the library components, and say that different rules
apply to each.
And in fact you do that: OpenSCAD constructs extend into +Z by default
(and +XY for cube and square), while BOSL2 constructs are centered by
default. OpenSCAD cube() and BOSL2 cuboid(), and OpenSCAD cylinder()
and BOSL2 cyl(), do very similar things but have different origin points.
But drawing that kind of line isn't possible when the library has
augmented the builtins, because those augmented builtins are then inside
both circles, and they might (in the future) conflict.
To be clear: I'm not saying that BOSL2's overrides of the builtins are
wrong. There's a tradeoff: cleaner overall API, versus future
compatibility risk. There are arguments on both sides. Personally, I
probably wouldn't have done it, because you already felt the need for
cuboid() and cyl(); once you are saying "here's the better way" it's not
much of a leap to "we recommend not using the old way". You chose
differently, and that's OK.
On 6/11/26 11:03 AM, Jordan Brown via Discuss wrote:
Eh, sort of. Yes, when a library introduces a "broad" feature, a
behavior that it presents as ubiquitous, and OpenSCAD evolves to have
a similar-but-different feature, that's a conflict of sorts, a
disharmony. However, one can still draw a line around the OpenSCAD
components and the library components, and say that different rules
apply to each.
And in fact you do that: OpenSCAD constructs extend into +Z by
default (and +XY for cube and square), while BOSL2 constructs are
centered by default. OpenSCAD cube() and BOSL2 cuboid(), and OpenSCAD
cylinder() and BOSL2 cyl(), do very similar things but have different
origin points.
That is not true:
https://github.com/BelfrySCAD/BOSL2/wiki/shapes3d.scad#functionmodule-cube
IIRC you should not be able to create a basic shape in raw OpenSCAD with
all valid inputs, then import BOSL2 and have it work differently; I'm
fairly certain that would be considered a bug unless there's a
documented good reason otherwise.
Cory
On 6/11/26 11:09 AM, Cory Cross via Discuss wrote:
On 6/11/26 11:03 AM, Jordan Brown via Discuss wrote:
Eh, sort of. Yes, when a library introduces a "broad" feature, a
behavior that it presents as ubiquitous, and OpenSCAD evolves to have
a similar-but-different feature, that's a conflict of sorts, a
disharmony. However, one can still draw a line around the OpenSCAD
components and the library components, and say that different rules
apply to each.
And in fact you do that: OpenSCAD constructs extend into +Z by
default (and +XY for cube and square), while BOSL2 constructs are
centered by default. OpenSCAD cube() and BOSL2 cuboid(), and
OpenSCAD cylinder() and BOSL2 cyl(), do very similar things but have
different origin points.
That is not true:
https://github.com/BelfrySCAD/BOSL2/wiki/shapes3d.scad#functionmodule-cube
IIRC you should not be able to create a basic shape in raw OpenSCAD
with all valid inputs, then import BOSL2 and have it work differently;
I'm fairly certain that would be considered a bug unless there's a
documented good reason otherwise.
Oh, I see now, you aren't counting BOSL2's cube, only cuboid. I
guess I don't have anything to add.