I have a tube in my library but I can't think a use for a hollow cube. Any
boxes I make have rounded corners and an open face.

On Mon, 16 Sep 2019 at 23:49, lar3ry lar3ry@sasktel.net wrote:

sampo-openscad19 wrote

As with others I agree this is a terrible idea for the same reasons.  But
some abbreviations can be handy.  BOSL provides a bunch of shortcuts like
this.

One thing that I find really puzzling is the opposition to standardization
that I see.  One poster said abbreviations are only ok if he made them up
himself.  I mean, yeah, I understand it might be a little more work---maybe
it takes a week---to get used to someone else's abbreviations.  I have a
hard time understanding how people wouldn't learn them from regular use.
(If it's so hard...how did they learn to use the native OpenSCAD commands in
the first place?)  It's really beneficial to have a more unified set of
extensions rather than everybody makes up their own abbreviations.  It means
posted code examples are more comprehensible, for example.  In general it
makes code more sharable.

One person suggested that we need to understand who the users are.  If the
users are indeed people with only a passing interest in modeling who want to
make 3 throw-away models per year, then there's no reason to do any further
development.  Why bother?

Maybe my frustration with the limits of OpenSCAD as it stands stem from
being a user with a deeper interest in real modeling.  Should I be using
some other tool?

Based on what I've seen I can say that (1) features you program are
extremely unlikely to be integrated into OpenSCAD in any official way and
(2) you would almost certainly be reinventing the wheel.  Almost everything
you suggest that can be done in libraries has already been done by somebody.
The BOSL and BOSL2 libraries support almost everything you propose.  (Note
BOSL is the old, stable library and BOSL2 is new, but currently unstable
version in development.)

See here for documentation:  https://github.com/revarbat/BOSL2/wiki  Most
of what you asked for is in shapes or transformations.  I would suggest
that you might take a look at BOSL2 and other libraries and see what
features are lacking from them before you start work on your own extensions.

On the matter of redefining primitives like cube(), it is already possible
to do this.  You just can't ever use the old cube() afterwards.  If you
really want to prevent users from making their own nonstandard versions
where cube() makes a sphere or something, you would need to ban redefinition
of primitives.  Allowing users to call the original cube() and know for sure
it's the original cube() should make things less confusing, not more so.

--
Sent from: http://forum.openscad.org/

nophead wrote

I was thinking of something that floats, but in retrospect, I guess the
slicer will take care of making it hollow.

--
Sent from: http://forum.openscad.org/

Non-FDM printers frequently want hollow shapes, with escape holes, to save on raw materials.

This email has been checked for viruses by AVG.
https://www.avg.com

On Mon, Sep 16, 2019 at 11:20:57AM -0400, Doug Moen wrote:

This isn't too difficult to implement, I'd think.
Just rename the current cube () primitive to __cube () and provide
a default module cube () definition that calls __cube()...

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

That doesn't work because the definition of cube overrides the original so
that __cube() calls the new one and creates recursion.

On Tue, 17 Sep 2019 at 11:03, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

What I meant was that the language can facilitate this option by
renaming the cube primitive to __cube(), and then having an
overridable module in place for the backwards compatiblity.

Now, the primitive may be able to do a few things that normal modules
cannot. For example, while it is easy to provide a centered=false
default on the module, you can just allways pass on centered=centered
on to the primitive. The "default" on the parameter will take care of
when the parameter is not specified. On the other hand I don't know
how to make the r=xx, d=yy behaviour on a cylinder. Does the primitive
"cheat" and do things that a user-written module cannot? Or are my
openscad skills simply not good enough. I don't know.

In any case, I was not suggesting that you could do this already by
redefining the prmiitve from your user-file.

Roger. 

On Tue, Sep 17, 2019 at 11:52:50AM +0100, nop head wrote:

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Sorry, yes that would work.

Currently it is fairly easy to override the geometric primitives with
something that produces the equivalent polyhedron or polygon without
calling the original. I do that myself for sphere() to make one that
includes the poles and equator.

To handle the multiple parameters I default the alternatives to undef and
then use is_undef(), so I think one can do the same as the original but it
would be quite a lot of code to do that and also check for errors, so speed
might suffer.

module sphere(r = 1, d = undef) {                  //! Override
sphere so that has vertices on all three axes. Has the advantage
of giving correct dimensions when hulled
R = is_undef(d) ? r : d / 2;
rotate_extrude($fn = r2sides4n(R))
rotate(-90)
semi_circle(R);
}

On Tue, 17 Sep 2019 at 12:10, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

rew wrote

Sorry, but I just can't see the point. What is so sacrosanct about the name
"cube" that someone can't work with a derived module called (say) "myCube"
without any need for developers to waste time changing the underlying code.

I get the impression that there is a large number of libraries with,
perhaps, a lot of close-but-not-perfect duplication amongst them. If that is
the problem then it should be fixed by some process of getting library
developers to work to a common standard, not by changing the core code.

...R

--
Sent from: http://forum.openscad.org/

Amen.  The problem isn't that we need to extend the language, it's that
we need to make library re-use (and subsequent improvement) productive
like most every other language.

We would almost certainly converge on a certain set of really good
libraries as a standard.  But trying to design them by committee into
the language is how you get things like the Java versions of 20 years ago.

On 9/17/19 7:34 AM, Robin2 wrote: