Open adamchalmers opened 4 days ago
I'm definitely in favor of the general idea of using namespaces.
Using the dot syntax is the most straight-forward and likely the easiest to learn for users. But it would mean that it's not easy to determine whether something is accessing a member of an object (must be runtime) or navigating the namespace (could be done statically).
Right now ZMA has a very limited constraint solver. This makes it hard to express relationships between points. For example, it's difficult to express a parallelogram. Here's my best attempt in KCL:
I had to break out some pen and paper to do geometry in order to figure out the correct relationships and get this code correct. It took some debugging, I got it wrong at first. We shouldn't make KCL users do this themselves.
One option is to offer a powerful constraint solver, so they can say "this parallelogram has diagonal distances of 6 and 15" using the Dimension tool. That tool lets users constrain points to be a certain distance away. That'll be a significant change from ZMA.
Another option is to offer a range of different stdlib functions to define a parallelogram, for example
parallelogram.withSides(number, number)
orparallelogram.withAngles(number, number)
to define them based on the minor/acute and major/obtuse angles.We can definitely do the former option, but we should also offer the latter option. The latter will be quicker to implement and will help users get through more and more tasks without needing a constraint solver. Of course, we can't possibly offer a function for every shape users will ever imagine. But we can offer a range of functions for common problems, to let users get further and further in their work before they need a constraint solver.
Suggestions:
These should be namespaced, both for readability and organization.