Because in the openscad language a later module definition replaces the
earlier one without an error. Arbitrary choice of the devs like many other
features. Bosl2 actually makes use of this to extend existing modules to
make them behave consistently with certain extensions.

On Wed, Jun 10, 2026 at 10:45 Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:

What a horror.

On 6/10/2026 1:09 PM, Adrian Mariano via Discuss wrote:

I can understand method overloading, but I would hope the syntax made it
clear that it was intentional, not just a brain fart.

I cannot understand how discarding code (the original module) without a
whimper is good or useful, but I defer to Adrian that this is a feature.

Personally, I would LOVE an option to produce a warning message any time
I accidentally re-used ANY name in my code: "variable", function,
module.  In other's code, I don't care.

I imagine I will hear little support for my position.

Jon

On 6/10/2026 3:44 PM, Lee DeRaud via Discuss wrote:

Just one more rule about using OpenSCAD.  There are no laws of physics
governing how programming languages should work, and in this case the
override rule serves BOSL2.  It's what keeps me from using BOSL2 (right
now, subject to change), but that's my personal angst, no one else's.

Glenn Butcher
Former compiler design teacher.

On 6/10/2026 12:38 PM, Jon Bondy via Discuss wrote:

On 6/10/26 1:28 PM, Jon Bondy via Discuss wrote:

It was added as a quick hack to allow overwriting a variable definition
by passing in new assignment values on the command line. Unfortunately
that hacky implementation had a side effect on the semantics of the
language and make it quite unusual.

Cory

I wouldn't call it a feature exactly.  It's more like we figured out a hack
to make use of a questionable design choice in a postive, feature-like
way.

Lee compares it to method overloading, but actually it was rather tricky to
make it work.  In BOSL2 our goal is to provide some feature extensions for
consistency, so that users can still use cube() or translate() and all the
BOSL2 features work properly.  (The alternative is basically to tell BOSL2
users they should never use any of a list of 11 builtins).  We intend for
this to be transparent---you should not be able to tell that we have
replaced the built-ins.  All code that ran before should still run and
produce the same result.  In order to do that, we need to replace cube()
with a new module but still be able to call the old cube(), which requires
"using" a library that defines things like _cube() that call the original
cube().  This is messy, complex, and not obvious.  It would be much better
if there was a simple way to redefine a module while still being able to
access the previous definition.

We have taken care to make sure that cube() does the same thing as before,
but there's nothing to keep a library from being more sloppy about a
redefinition, or even nefariously redefining cube() to make cubes that are
1 unit too small, so in that respect, this is a dangerous feature, though a
cleaner redefinition feature wouldn't prevent this sort of thing.

On Wed, Jun 10, 2026 at 4:44 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:

[ Sigh.  I came to rely on a Thunderbird add-in that lets you set rules
for automatically selecting an appropriate address to send from, and
over the last few years TB upgrades have broken that add-in several
times.  Those typing habits are difficult to overcome. Thunderbird is
the worst mail client ever, except for all of the others. ]

On 6/10/2026 11:38 AM, Jon Bondy via Discuss wrote:

It's definitely a power tool with sharp edges and few safety features. 
I think it could have more safety features, to make it more difficult
to shoot yourself in the foot.

Adrian says:

But a cleaner feature could prevent accidentally overriding a
previously-defined module or function.  Indeed, an intentional but
poor-quality override would still be a problem.  Another concern is that
the next version of OpenSCAD might include new features for the core
module/function that conflict with the features added by the override.

Cory says:

That explains variable overriding.  It doesn't explain module/function
overriding.

Yeah, it's true that a special override feature would not be accidentally
activated.  At least the way we've done it, I don't think new features
could conflict with our override, but if they involve new parameters, the
override wouldn't support them simply because it wouldn't accept them and
pass them on to the original module, so it would cease to be transparent.
Too bad there's no way to gather all the parameters of a module and pass
them to a child module.

On Wed, Jun 10, 2026 at 9:08 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

On 6/10/26 6:07 PM, Jordan Brown via Discuss wrote:

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:

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:

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:

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:

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

On 6/11/2026 5:02 AM, Adrian Mariano wrote:

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 10:42 AM, Adrian Mariano 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.

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:

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:

Oh, I see now, you aren't counting BOSL2's cube, only cuboid. I
guess I don't have anything to add.