I HAVE tried suggesting ways to fix the broken use<> in a way that would provide namespaces, though.
lib = use<lib.scad>;
foo = lib.func(blah);
Yes, my ideas are along much the same line, though I don't think it needs magic syntax - use() would just be a function that returned an object.
lib = use("lib.scad"); seems reasonable to me. But it really needs module literals to be useful.
I never really tried to implement it, but the design in my head still had a gap for determining which variables/modules/functions in the used file were included in the object. It could be "all of them", but that isn't always the right answer.
Excluding variables in use<> made it unusable (heh) for a library with constants. Export em all. If you desperately must provide gatekeeper support, add a keyword to hide elements. private foobar.
And of course since it would squash module, function, and variable namespaces into one object-member namespace, that would be a bump in the road for adopting it for existing libraries. And it would depend on module references, which are still in limbo with PR#4478.
The libraries will cope and be redesigned around the new paradigm. BOSL3 would probably add a f_ prefix to functions that share names with modules. If this had been part of the language ten years ago, we'd already be using it.
> On Jun 11, 2026, at 6:18 PM, Jordan Brown <openscad@jordan.maileater.net> wrote:
>
> On 6/11/2026 5:36 PM, Revar Desmera wrote:
>> I HAVE tried suggesting ways to fix the broken use<> in a way that would provide namespaces, though.
>>
>> lib = use<lib.scad>;
>> foo = lib.func(blah);
>
> Yes, my ideas are along much the same line, though I don't think it needs magic syntax - use() would just be a function that returned an object.
lib = use("lib.scad"); seems reasonable to me. But it really needs module literals to be useful.
> I never really tried to implement it, but the design in my head still had a gap for determining which variables/modules/functions in the used file were included in the object. It could be "all of them", but that isn't always the right answer.
Excluding variables in use<> made it unusable (heh) for a library with constants. Export em all. If you desperately must provide gatekeeper support, add a keyword to hide elements. `private foobar`.
> And of course since it would squash module, function, and variable namespaces into one object-member namespace, that would be a bump in the road for adopting it for existing libraries. And it would depend on module references, which are still in limbo with PR#4478.
The libraries will cope and be redesigned around the new paradigm. BOSL3 would probably add a `f_` prefix to functions that share names with modules. If this had been part of the language ten years ago, we'd already be using it.
- Revar
