Feature request: extension of cube center functionality.
On 29 Nov 2020 at 16:59, Jean-Paul Louis via Discuss wrote:
What you're asking is the perfect example of feature creep. A feature that does not add any value
to the existing code.
And your response is a perfect example of the reason I use the BOSL2
library for almost everything now. I say almost, because I have a friend that I
collaborate with on some designs, who apparently can't use BOSL2 on his
Linux box.
If you really want it, create a module that will do what you want, and don't bloat a good feature with
useless stuff.
What you find useless is certainly not useless to everyone, and in particular,
folks just starting with OpenSCAD, having to noodle their way through things
that you find simple, are often so intimidated that they end up never using it
again.
Just my two cents,
Exactly.
lar3ry wrote
On 29 Nov 2020 at 16:59, Jean-Paul Louis via Discuss wrote:
What you're asking is the perfect example of feature creep. A feature
that does not add any value
to the existing code.
And your response is a perfect example of the reason I use the BOSL2
library for almost everything now. I say almost, because I have a friend
that I
collaborate with on some designs, who apparently can't use BOSL2 on his
Linux box.
Seems odd. BOSL2 works fine on my Linux box...and there is nothing machine
dependent about it. It's developed for the stable version of OpenSCAD and
doesn't work properly with some of the recent snapshots. Could it be a path
setting issue?
If you really want it, create a module that will do what you want, and
don't bloat a good feature with
useless stuff.
What you find useless is certainly not useless to everyone, and in
particular,
folks just starting with OpenSCAD, having to noodle their way through things
that you find simple, are often so intimidated that they end up never using
it
again.
As you know, I'm a big proponent of libraries. And yet that doesn't mean
that I think features like this necessarily belong in the base language. It
would be nice if it was possible to more cleanly extend the functionality of
base modules by redefining existing modules and then calling the base
language module. But it definitely seems reasonable to keep the base
language simple. I'd rather see developments in the base language that
implement fundamentally different things that are really hard to do in
userspace rather than trying to build out more complex interfaces that are
trivial userspace extensions.
The point is that you have the option of using a library, be it BOSL2 or
some other library you choose, to provide these extensions. So what is the
argument for including them in the base language? I would suggest that
libraries should play a bigger role. Nobody uses C or Python without using
the libraries. If you think users are being scared away the answer is to
introduce them to OpenSCAD with some suitable library.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list-2 wrote
Kevin,What you're asking is the perfect example of feature creep. A
feature that does not add any value to the existing code. If you really
want it, create a module that will do what you want, and don't bloat a
good feature with useless stuff.
Well, don't judge this hard. There are a lot of feature requests like this
around in this forum and they all have their right.
You can certainly find workarounds by writing some specific modules or lets
say rewriting OpenSCAD's primitives. It was one of the first steps to write
my own shortcuts library when I started programming with OpenSCAD.
However,
-
while we can overload a native module, the price is that we loose access
to the native module. Therefore, we can't implement our own cube by
referring to the native cube module and have to use either different names
or different techniques (like linear_extrude for implementing a cube) -
we can't quest modules about their objects in lack of a boundingbox()
function and so on. Therefore, we can't align or center any stuff, without
knowledge of the critical design parameters, which is a nightmare especially
with imported objects. -
in the early days of OpenSCAD native modules were defined in a kind of
stubborn fashion with respect to their defaults and parameter names. E.g. a
cube/square is not centered at all, a cylinder/circle is partly centered,
cylinder() and linear_extrude() don't allow for a negative height and also
use different parameter names for defining the height. Operators like
translate, scale and rotate have their own weired parameter logic instead of
allowing calls like translate(x=10).
This means there is a lot stuff one can criticize and might want to have
corrected in the native appearance of OpenSCAD. Of course one can find and
put workarounds into an own library. But this has the effect that every
second programmer ends up writing and maintainig his own lib, while others
don't get tired to extol specific libraries like BOSL2.
In this sense I think the feature being requested by the TS has all rights
to be treated as a serious request. However the proposed solution might be
to specific, since all OpenSCAD objects more or less suffer from this
alinging problem, which triggers the request for an align-operator
module align([x,y,z]=[0,0,0]) children;
and/or even better:
module align(x=0, y=0, z=0) children()
where a negative, zero, or positive value for x, y, z enforces an alignment
to the negative side, center or positive side of the respected axis.
While such an operator could be used in a very general way it might bring up
the question whether it would have to use CGAL if applied to a Boolean
expression. Without having thought about this issue extensively my idea
would be that a boundingbox logic could do.
--
Sent from: http://forum.openscad.org/