over your entire program, or in a more limited scope.

That is no longer true. It works in the last release but it got broken
afterwards. It only affects the file you put it in an any includes. It no
longer affects used modules unless you put it on the call stack. And any
$variables at file scope in used modules are ignored by functions and
modules unless you copy them into normal variables and use those.

On Mon, 25 Aug 2025 at 20:21, Torsten Paul via Discuss <
discuss@lists.openscad.org> wrote:

On 8/25/2025 9:21 PM, Torsten Paul via Discuss wrote:

An interesting point.  Further thought required.  It can certainly be
handled - the library could routinely stow away the caller's value, and
restore it when calling children() - but it would be inconvenient.

But what would be a better answer?

• "Yes, people want a different default, but we can't do it. Sorry."
• New verbs for cube, linear_extrude, and cylinder.
• Some new #pragma-type mechanism, maybe with file scope.
• Something based on ordinary variables, so that they are lexically
  scoped. (But we don't have any precedent for modules consuming
  ordinary variables.)
• ...?

Having it as a preference item seems like a non-starter, because it
would mean that the user would have to tweak preferences to match each
model.

On 8/25/2025 9:40 PM, nop head via Discuss wrote:

Yes, top-level $ variables in used files no longer work.

On 8/25/2025 12:00 PM, Roger Whiteley via Discuss wrote:

I expect that it's over many or most people's heads.  It's corner cases
stacked upon corner cases.  Of course, we want to address those corner
cases, but they are often narrow enough that it's hard to follow what
they really mean.

Easier to use?  Maybe, in some cases.  Using objects, you get the size
of a piece of text using something like

tm = textmetrics("Hello");
size = tm.size;

Without objects, that second line would need to be either

size = tm[1];
size = get(tm, "size");

For more complex data structures with multiple layers it gets more complex.

fm = fontmetrics();
family = fm.font.family;
family = fm[3][0];
family = get(get(fm, "font"), "family");

Revar saw a substantial performance boost because objects let him use a
smarter data structure.

Objects with methods (which are tied up in the discussions we've been
having) help to avoid polluting the namespace.  If some particular data
structure has a set of functions or modules that operate on that data
structure, representing that structure as an object would let you call
them  using the object rather than requiring that they have names in the
global namespace that might conflict with names in your program.

One hope is that we'll eventually be able to encapsulate an entire
library in one object, so that you would say something like:

bosl2 = import("BOSL2/std.scad");
bosl2.cuboid(...);

and almost totally avoid naming conflicts between the library and the
calling program, or between two libraries.  Today, any new BOSL2 release
might add a name that conflicts with your existing program.  Or you
might add a name, not knowing that it conflicts with a BOSL2 name.

See the animation demo that I set out in the followup to my introductory
message for object().  The data structure that it uses would be No Fun
At All to try to represent without objects. (Not impossible, just a lot
uglier.)

Objects should make life easier for some library developers, and making
life easier for library developers lets them make more and better
libraries for you.

There's no direct gain for geometric operations.  (There's a different
feature that will help there, that nobody is working on at the moment.)

As I understand it, defining a library as an object with module references, the definition would be something like:

Object(
stuff = 0,
nonsense = 1,
m0 = module() {
…
}
m1 = module() {
...
}
)

Having to put all of the code for the modules inside the object parens would be, well, impossible.. There would need to be some way of defining the modules more conveniently outside without entering the namespace. If "import" is a new third complement to use and include, that would do it. If it follows use/include rules, perhaps any module name starting with say “_” would not be visible.

Now that I think about it a little, I suspect your imported file is not written as an object but the import creates the object. Works for me.

-Bob

[ I'm trying to avoid deep dives that aren't properly represented by the
subject, so I've changed it... ]

On 8/26/2025 2:23 AM, Bob Carlson wrote:

Maybe, maybe not.  Nobody's really implemented it yet.  (Except that
what you said would at least sort of work today.)

Why?

I don't understand what you mean by "outside" and "without entering",
and why it would be desirable.

Why?  (And, BTW, one of the reasons for doing this would be to get rules
that are a bit different from either use or include, because they both
have problems.)

That's a possibility that's been discussed, but why do you think it
would work better?

Jordan,  thank you, now that makes sense and I can work my head around
that, conflicting names for values is definitely [from my experience]
one of those lessons in scope OpenSCAD users have to get their head
around, the bits of BOLTS [sorry] I do use have help me understand other
useful techniques.

Having said that, I don't use BOSL2 at all, I tried when I was just
learning OpenSCAD and gave up because I needed to work with what I
understood, six years later, I think its time.  I found a problem that I
don't know how to solve [yet].

I use the abstraction from your bosl2 = import example as a method to
avoid having to rename names in modules, so there's definitely value in
Objects with methods.

All I have to do know is get Debian 12 desktop to let me install a much
newer Flatpak nightly.

Roger.

On 26/08/2025 00:33, Jordan Brown wrote:

I am really glad this is getting attention!

A library like BOSL2 has hundreds (>1000?) of modules. If the syntax is like I surmised (and I’m pretty sure that’s just my memory of someone else’s guess) then there has to be an object member for every callable module. If all those are between the ()s of the object call, then I think you see the problem.

Outside of object(<inside>)

Entering the namespace was a clumsy phrase. What I mean is that there should be a way to have modules, functions and variables in the library that cannot be seen by the importing code.

Even in my small library I have modules that I do not want to expose in an include, they are called within the library but not intended to be exposed. I put a “_” in front of the name. This doesn’t actually hide them but makes them less likely to interfere accidentally with other libs. If the import function hid them automatically, the would be a good thing. Another way to do it would be to use a marker similar to what the customizer does. Everything after the marker would be internal to the library. And I am sure there are other methods too.

I think this was discussed before. A new type of include could have new and different rules that would avoid the backward compatibility issues of adding things to include and use. The rules of the new import should make it as simple as possible to convert existing libraries to an object style presentation. So, an “import” that does a lot of the work would really help.

I also think

bosl2 = import(“BOSL2/std.scad”);

Then calling bosl2 modules as

bosl2.cuboid(..);

It’s much better if the code says what library it is calling.

-Bob

PS I just realized my MSCS turned 50 a couple months ago! Unfortunately I was not 5 years old when I got it.

On 8/27/2025 1:45 AM, Bob Carlson wrote:

No, actually, I don't.  Is it odd to have a function take thousands of
parameters?  Yes.  Will it work?  Also yes.

I'd like to see the OEP8a / PR#6081 object syntax { a: 1, b: "banana" },
but I believe that would only slightly change the picture.

A more interesting question is what you might call sub-libraries.  BOSL2
has a bunch of files that you can include or not, and they need to be
able to interact with one another. That's straightforward enough if each
sub-library has its own dedicated and well-known name in the global
namespace, but less obvious if they don't, if the caller specifies the name.

I understand the desire, but I wouldn't personally add such a mechanism
because I'd say that the additional cost would outweigh the benefits. 
Once we get some of these namespace management capabilities, those
"internal" names won't collide with the caller or with other libraries. 
The only reason to hide them is to defeat somebody who is deliberately
trying to use a name that you don't want them to use.  At work we have
mechanisms like that, because there are always customers and ISVs who
break the boundary and then whine when a future release isn't compatible

• and even if we've made it clear what the rules are, we have to take
  the support call and deal with the unhappy customer.  The picture here
  is very different.

I like that strategy because there ends up being only two namespaces
where collisions can occur:  the file name, and $ variables.  There are
few enough file names, and the cost to make them longer (like adding
"BOSL2/") is low, so I think that's in good shape.  $ variables are more
of a problem.