[OpenSCAD] multmatrix expands the input matrix to 4x4?
avm4 at cornell.edu
Tue Jul 2 23:19:42 EDT 2019
> On 02.07.19 20:09, adrianv wrote:
>> Why do you call it "poking holes"? It's what OpenSCAD does.
> Yes, and that's what I meant. Things are not clearly specified
> so there are lots of undefined places. The first tiny steps for
> reducing that are the latest improvements implementing warnings
> for a number of those cases.
So what should the behavior be for multmatrix()? It should be an error to
pass a matrix not exactly 4x4? One could argue that being able to pass 3x3
is not unreasonable. I tend to think that excess data should be an error,
e..g passing a 5x5 shouldn't be accepted, but it's not obvious that the
current behavior is otherwise bad. Is there harm in alllowing a matrix
subset? (If I were to pick a place where I thought we would get significant
benefit from the efforts of an OpenSCAD programming, I certainly wouldn't
point to this issue.)
What's the bottom line for the "approved" ways to use multmatrix()?
> So I guess there's 2 options:
> 1) Define all the holes as feature and basically make it impossible
> to change the OpenSCAD language.
> 2) Slowly move to a clearer specification by improving both code
> and documentation.
> I hope we will end up with the 2nd option, and I hope people will
> help going into that direction.
I don't have a feeling like OpenSCAD is really moving anywhere, like I
should have an expectation that it will improve. The fact that 4 years
passed between releases suggests a pretty conservative approach, without
much change. It seems like suggestions of changes are met with the
response that those who could execute such changes lack the time or
inclination to do so (and that it's unreasonable to request changes because
it's a volunteer effort.) So it's really not apparent how someone (who is
not prepared to write code for OpenSCAD itself) could help improve matters
in the core language.
Here's another observation: if behavior is not documented then perhaps it
decreases the likelihood of code relying on that behavior, but also it's
difficult for people to observe that the behavior is bad, since it's secret.
It seems unlikely to get "fixed". Perhaps behavior deemed bad should be
documented as "quirks" or something like that, with the indication that
quirk behavior may change in the future, and code should avoid relying on
it. Or does someone already have a list of these sorts of concerns?
Sent from: http://forum.openscad.org/
More information about the Discuss