On 12/28/2020 7:32 AM, adrianv wrote: > JordanBrown wrote >> >> I'm concerned about somebody who naïvely goes and tweaks their >> standard library because they can, then six months later, having >> forgotten that tweak, runs into trouble and asks for help.  They give >> their entire source file, with no include/use statements (or with >> "use <stdlib.scad> ", depending on how the standard library works), >> and everybody is mystified. And yeah... it's not exactly "libraries >> are a support disaster".  It's "sources are a support disaster". >> >> And maybe that's just part of the cost of doing business in the FOSS >> world, so to speak. >> > This just seems like a really bizarre concern to me. Have you had this > problem in some other context? > Yes and no.  Perhaps I'm just being paranoid. In a work context (Oracle's Solaris Operating System), customers do the strangest things, and then call for support. I've personally hacked FOSS when it didn't work right (Western Digital bookshelf server did NTP wrong). I've overridden OpenSCAD builtins when they didn't work, and then forgotten that I'd done so.  (I don't remember the details, but rotate was doing something very slightly wrong on 90 degree angles, so I replaced it with a version that was correct.) ---Changing gears to a minimalist OpenSCAD --- First, to be clear, it was a thought experiment, not a proposal. What would the advantages and disadvantages be of aggressively pushing non-performance-critical stuff out into userspace, as part of the standard environment that you get without any use/include? Advantage:  Many more people could contribute to the "standard" language.  Bugs would be less likely, and less likely to be fatal. Disadvantage:  Many more people could contribute to the "standard" language :-).  There would be more push for including everybody's pet feature.  There would be more 70% solutions that sort of work being pushed for inclusion.  There would be the possibility of the "forgotten tweak" that I discussed above. > Since we have to implement sweep operations (which are *much* harder > than linear extrude) in user space, really, why not linear_extrude? Sweep sure seems like a candidate for moving into C++. > One thing that this proposal opens the door to is more people trying to > submit changes to the core. Unlike the bizarre hack concern above, I think > if it was easy to extend the core then people would be proposing all sorts > of changes. I think it makes more sense to keep things as they are and > allow libraries to extend the core (as is already basically possible). That > is, the various extensions you're talking about can be provided by > libraries, not in the core. Yes, though, again as a thought experiment... does this mean that we *don't* add O(1) features to the default environment?  Or that they must be added as C++? If we had the ability to override a C++ module from userspace, while still being able to invoke it when needed, and we decided that we wanted the "control whether the polygon approximation of a circle is inside or outside the theoretical circle" feature discussed in another thread, what would we do?  Would we say "nope, must go in a library that you explicitly use/include"? Would we say "OK, but has to be implemented in C++"?  Or would we implement it in userspace in a library that is automatically included? That last sure seems like the right answer, *if* there's a serious throttle on the flow of features. And with the concerns I mentioned about supporting people when they do their own tweaks.