Hi,
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";
echo(foo());
echo(foo);
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
such thing?
Thanks.
Hi,
On Apr 13, 2016, at 16:22 PM, Kuba Marek blue.cube@seznam.cz 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.
-Marius
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
use single_namespace;
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.