I've been playing with OpenSCAD for a few days now and I found two
things that I really miss.
First is inability to pass functions as function parameters, the second
is inability to get vertex/faces data from children() call.
I'd like to try implementing these, starting with function references.
What I want to ask is how realistic this one seems to someone more
experienced with OpenSCAD internals and what's the workflow here for
changes like this? (Pull request to git once I'm done? Or pull request
without changes to discuss it first?).
With the function pointers I see a problem of it being a backwards
incompatible change; code like this:
function foo() = "bar";
foo = "baz";
would change meaning. How careful is OpenSCAD about breaking
changes like this? I didn't see anything similar to python's "from
__future__ import something", did I just miss it or is there really no
> On Apr 13, 2016, at 16:22 PM, Kuba Marek <[hidden email]> wrote:
> I'd like to try implementing these, starting with function references.
There already exists a proposal for how this would fit into OpenSCAD.
Take a look here (warning: it’s quite a long document): https://github.com/doug-moen/openscad2
So far, we’ve approached this topic by trying to implement one feature at a time from this proposal. Some of the features do require deep refactoring.
I think Doug would be better able than me to evaluate the realism of implementing function references and how deep that rabbit hole goes.
Kuba said "How careful is OpenSCAD about breaking changes like this? I didn't see anything similar to python's "from __future__ import something", did I just miss it or is there really no such thing?"
There is no such thing in the language right now. What we sometimes do is put configuration switches into the Preferences for enabling experimental new language features. This preferences are typically used in developer releases, and removed in major releases. I don't think that's adequate for a change as big as unifying the function, module and variable namespaces into a single namespace.
If we wanted to use the Python strategy, then we could introduce a new syntax like
to specify that the current script uses a single namespace for variables, functions and modules. Of course, this means that if we introduce a built-in sort() function with an optional comparison function argument, or if somebody creates a library module with a function argument, then you'll need to write 'use single_namespace;' in order to use those new APIs.
The other part of the Python strategy is that, in some future release, the single namespace becomes default behaviour, and you get a single namespace even without using that syntax. The down side of this is that old scripts on Thingiverse, github, and elsewhere will bit decay and eventually stop working.
The OpenSCAD2 document proposes a different backwards compatibility strategy, one that doesn't require 'use single_namespace;' in order to use new built-in or library modules that use function arguments, and one that preserves backwards compatibility for old scripts indefinitely, but frankly, it's kind of a one-shot deal, and is a lot more difficult to implement.