parkinbot wrote:

I'm a big fan of user defined errors; they are important for debuggability.
Torsten has already implemented assert in the snapshot, and I'm
happy about that.

As for faking a type system using record fields. Well yes I am planning to
do something like that in my new geometry library. And I will be using
assertions to report "type errors".

I'm not convinced that traditional "OOP with classes" is actually the right
tool for the job. I've been an OOP programmer for a long time, and I no
longer have any romantic ideas about it. It's a powerful tool, but it's also
overly complicated and has problems and limitations.

What I actually need is the ability to classify geometric shapes along
multiple independent axes. The Javascript built-in typeof operator,
for example, doesn't help with this at all.

I plan to represent geometric shapes as records. I can classify shapes
by storing values in record fields. I can test if a shape has a specific
property by querying if it defines a specific named field, or if that field
contains a specific value. These tests will be encapsulated in functions
like is_polytope(), which tests if a shape is a polygon or polyhedron with
vertex information available at preview time. (E.g., union and intersection
do
not compute vertex information at preview time.) Once you've established
that a shape has a particular property, then you can safely access
the record fields associated with that property.

The question is whether OOP with classes, or some similar scheme,
would actually make my library code so much easier to write and maintain
that it would be worth the cost and complexity of implementing OOP.
I'm betting the answer is no, but we'll see.

Abstract theorizing can only take you so far. For me, the discipline
of writing working code, debugging it, refactoring it until it is clean,
always seems to lead to a somewhat different destination than where
I thought I was going.

So I'm not going to implement a full OOP system just in case I happen
to need it for my geometry library. Instead, my plan is to write the
simplest
code that works, and see where that leads. And I think that keeping
the language small and simple is important for useability.

On 19 November 2016 at 06:59, Parkinbot rudolf@parkinbot.com wrote:

Functions have the same behaviour:

b = 2;
function x(a) = [a,b];
echo(x(1));      // ECHO: [1,2]
echo(x(1, b=3)); // ECHO: [1,3]

Marius has said that he doesn't like people writing code like this, and
that this is a bug he'd like to fix.

Also, there is an open issue about the fact that OpenSCAD fails to report
that you have passed a bad argument to a function or module:

https://github.com/openscad/openscad/issues/1574

If we fix issue 1574, then we will also remove the "feature" that passing
bad named parameters to a module or function causes weird dynamic scoping
behaviour. I am in favour of fixing 1574.

If you really want the function 'x' to accept an optional b= argument, then
the right way to code it is like this:

b = 2;
function x(a, b=b) = [a,b];
echo(x(1));      // ECHO: [1,2]
echo(x(1, b=3)); // ECHO: [1,3]

So I think that fixing 1574 is not a big deal.

On 20 November 2016 at 01:38, runsun runsun@gmail.com wrote:

doug.moen wrote

So we go from OpenSCAD 'silently' failing (as it does for very many cases),
i.e. ignoring bad grammar, to it slapping you in the face?

As I pointed out earlier 'fixing' this will break a. write.scad, AFAIK
probably one of the more wide spread libraries, b. all those others which
took write.scad as an example.

At most 'fixing' should be a warning.

Write.scad extract, one of many examples:
Call:
writecircle(text,where+[0,0,height/2],radius-h,rotate=rotate,font=font,h=h,t=t,
space=space,east=east,west=west,middle=middle,ccw=ccw);
Definition:
module writecircle(text,where,radius){

So if I want to accept all possible variables...
Does this 'fix' also apply to '$' special variables? So $fn etc will also
fail?

Further food for thought, how does that apply to children()?

Admin - PM me if you need anything, or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19264.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Isn't it trivial to fix write.scad et al by adding the missing parameters
as Doug showed?

The $variables need to work as they do know.

On 20 November 2016 at 12:49, MichaelAtOz oz.at.michael@gmail.com wrote:

MichaelAtOz said fixing issue 1574 will break "write.scad", unless we only
issue warnings for bad labeled arguments in user defined functions and
modules.

Thanks, that's useful information, and I'll add it to the github issue.

What do you mean?

On 20 November 2016 at 07:49, MichaelAtOz oz.at.michael@gmail.com wrote:

I am not sure that this is pertinent to this discussion but it is sometimes
so hard to debug as issue 1574. I have just crossed with it and isolated it
in the code (using version 2015.03-2):

The console ouput:

--
View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19272.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Yes the second definition of d3 needs d2, which needs d1 which needs n but
it gets moved to where the first definition of d3 is where they are not in
scope.

On 20 November 2016 at 18:47, Ronaldo rcmpersiano@gmail.com wrote:

And to help the user it complaints of n and d2?

2016-11-20 17:04 GMT-02:00 nop head nop.head@gmail.com:

On 11/20/2016 08:18 PM, Ronaldo Persiano wrote:

Well, this has been discussed to death in various slightly
different cases. The problem is that ideally the reassignment
should warn or even better throw an error. But at this time
it would break pretty much all cases where "-D" is used
from command line.

I have no idea if that was done by intention or just a
coincidence when the "-D" flag was introduced, but replacing
the assignment where it was listed first makes the simple
"just add all the -D stuff at the end of the script"
possible.

So, yes, it's an ugly bug. But it's not trivial to fix.

ciao,
Torsten.

The OpenSCAD scoping rules are terrible. Really hard to understand. The
worst I've seen in any language.

I fixed this in my next-gen OpenSCAD prototype. I have a different scoping
rule for definitions at the top level of a script. The scope of every
variable, function and module definition is the entire file. The order in
which you write definitions doesn't matter. (Aside from redefinitions of
the same name, obviously.) This scoping rule is very simple, easy to
understand (the order of definitions doesn't matter), and it fixes the
problem Ronaldo describes.

I think that, for the top level of a script, this is backwards compatible.
This problem normally only bites people at the top level, so fixing the
problem at the top level is a win.

On 20 November 2016 at 13:47, Ronaldo rcmpersiano@gmail.com wrote: