There has been lots of talk about objects in the next major release (which I am definitely looking forward to and consider very important), but one other thing that I often do (or more accurately do a workaround of) in my libraries and/or other code is overload functions & modules. This may seem like a strange thing for an untyped language where optional parameters is as often as it is, but untyped is not 100% true (just look at the is_* functions). What I usually do is just create a series of if then statements to create a recursive function or method. This works, but it would be much easier to read code when it is specified in the parameters. It would also, in some cases, make it easier to enter the parameters (depending, for example, on whether they came from a list or entirely separate places). I also think that being able to overload functions & modules will make it much easier to make the transition to using objects much easier, since we will be able to keep our old code and just make an overload. Nathan Sokalski njsokalski@hotmail.com<mailto:njsokalski@hotmail.com>

Could you provide a code snippet demonstrating the problem? - Cory On August 23, 2025 8:13:31 PM EDT, Nathan Sokalski via Discuss <discuss@lists.openscad.org> wrote: >There has been lots of talk about objects in the next major release (which I am definitely looking forward to and consider very important), but one other thing that I often do (or more accurately do a workaround of) in my libraries and/or other code is overload functions & modules. This may seem like a strange thing for an untyped language where optional parameters is as often as it is, but untyped is not 100% true (just look at the is_* functions). What I usually do is just create a series of if then statements to create a recursive function or method. This works, but it would be much easier to read code when it is specified in the parameters. It would also, in some cases, make it easier to enter the parameters (depending, for example, on whether they came from a list or entirely separate places). I also think that being able to overload functions & modules will make it much easier to make the transition to using objects much easier, since we will be able to keep our old code and just make an overload. > >Nathan Sokalski >njsokalski@hotmail.com<mailto:njsokalski@hotmail.com>

There is no problem, it was just a feature request to be able to overload instead of using conditions, type testing & recursion to simplify code readability Nathan Sokalski njsokalski@hotmail.com<mailto:njsokalski@hotmail.com> ________________________________ From: Cory Cross via Discuss <discuss@lists.openscad.org> Sent: Saturday, August 23, 2025 9:29 PM To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> Cc: Cory Cross <openscad@corycross.org> Subject: [OpenSCAD] Re: Function & Module Overloading in Next Major Update Could you provide a code snippet demonstrating the problem? - Cory On August 23, 2025 8:13:31 PM EDT, Nathan Sokalski via Discuss <discuss@lists.openscad.org> wrote: >There has been lots of talk about objects in the next major release (which I am definitely looking forward to and consider very important), but one other thing that I often do (or more accurately do a workaround of) in my libraries and/or other code is overload functions & modules. This may seem like a strange thing for an untyped language where optional parameters is as often as it is, but untyped is not 100% true (just look at the is_* functions). What I usually do is just create a series of if then statements to create a recursive function or method. This works, but it would be much easier to read code when it is specified in the parameters. It would also, in some cases, make it easier to enter the parameters (depending, for example, on whether they came from a list or entirely separate places). I also think that being able to overload functions & modules will make it much easier to make the transition to using objects much easier, since we will be able to keep our old code and j ust make an overload. > >Nathan Sokalski >njsokalski@hotmail.com<mailto:njsokalski@hotmail.com> _______________________________________________ OpenSCAD mailing list To unsubscribe send an email to discuss-leave@lists.openscad.org

I'm skeptical that a sufficiently useful overloading feature can be devised. I have lots of code with ladders of cases that might be recursively handled, or maybe just conditionally handled, but the specific tests that determine the set of cases are quite varied and depend on the specific problems. It's not even clear that for the simple cases it would cover that it would result in more readable or maintainable code, since it would break up the definition into different parts, and possibly require repeating the parameter line, which might have many parameters shared by both versions. On Sat, Aug 23, 2025 at 10:08 PM Nathan Sokalski via Discuss < discuss@lists.openscad.org> wrote: > There is no problem, it was just a feature request to be able to overload > instead of using conditions, type testing & recursion to simplify code > readability > > Nathan Sokalski > njsokalski@hotmail.com > ------------------------------ > *From:* Cory Cross via Discuss <discuss@lists.openscad.org> > *Sent:* Saturday, August 23, 2025 9:29 PM > *To:* OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org > > > *Cc:* Cory Cross <openscad@corycross.org> > *Subject:* [OpenSCAD] Re: Function & Module Overloading in Next Major > Update > > Could you provide a code snippet demonstrating the problem? > > - Cory > > > On August 23, 2025 8:13:31 PM EDT, Nathan Sokalski via Discuss < > discuss@lists.openscad.org> wrote: > >There has been lots of talk about objects in the next major release > (which I am definitely looking forward to and consider very important), but > one other thing that I often do (or more accurately do a workaround of) in > my libraries and/or other code is overload functions & modules. This may > seem like a strange thing for an untyped language where optional parameters > is as often as it is, but untyped is not 100% true (just look at the is_* > functions). What I usually do is just create a series of if then statements > to create a recursive function or method. This works, but it would be much > easier to read code when it is specified in the parameters. It would also, > in some cases, make it easier to enter the parameters (depending, for > example, on whether they came from a list or entirely separate places). I > also think that being able to overload functions & modules will make it > much easier to make the transition to using objects much easier, since we > will be able to keep our old code and j > ust make an overload. > > > >Nathan Sokalski > >njsokalski@hotmail.com<mailto:njsokalski@hotmail.com> > _______________________________________________ > 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 >

module myCube(number dim) { ... }
module myCube(list dim) { ... }

module myCircle(r) { ... }
module myCircle(d) { ... }

On 8/24/2025 2:13 AM, Nathan Sokalski via Discuss wrote: > There has been lots of talk about objects in the next major release I actually think that anything past object() should *not* go into the next major release, because it will add complexity and risk, and we should be in the "low risk only" mode at the moment. object() itself is pretty safe, but I would call it the *most* I would add to the release at this time, and wouldn't complain if it was pushed to the next release. > but one other thing that I often do (or more accurately do a > workaround of) in my libraries and/or other code is overload functions > & modules. Could you give an example of exactly what you mean? I think maybe you mean something like module myCube(number dim) { ... } module myCube(list dim) { ... } so that depending on the type of the argument, different implementations get called. Or maybe you mean something like module myCircle(r) { ... } module myCircle(d) { ... } so that depending on the argument(s) supplied, different implementations get called. I think there's basically no chance of the type-based scheme. That's just not the style of the language.  The argument-based scheme, maybe, but I wouldn't hold my breath.