Stimulating and supporting code re-use

[raydeleu]

Something that came to my mind while analysing the code that was used to prepare a model of a plug with "grips" to create a tight fit (see #36 (comment))

The value of the Replicad concept is that a user can take functions, prepared by a different user to enhance his/her model. The "grip" idea used in this model has certain elements in it that - when generalized - are very useful to other users. For example, the function to create a radial array is interesting and can be used for all kinds of patterns. Another is the idea to create a small protrusion to create a tight fit.

In this example I would think that the solution envisaged by @lf94 using lofts would already be more generally applicable. It would also work on rectangular plugs, not only circular ones. I assume that it would also solve the difficult calculation of the rotation angle for the grip-cylinders. And using a standard loop instead of a mapping function to create a circular array where you can adapt the number of grips would be wider applicable and easier from a user perspective.

The questions then are:

• how we can persuade a user to create a separate function instead of a tailor-made solution,
• how can we make the function more understandable,
• what are guidelines to make a function more generic, so applicable to a wider range of models
• when a user has built such a useful function, how is this visible to other users of the library. Would it be possible to create something like a search tool where you type "array" or "grip" and you are lead to a boilerplate for a function to create this?

[raydeleu]

A simple approach how to achieve a concept like boilerplates is using the snippet functionality in your favorite editor. See

https://www.geeksforgeeks.org/how-to-create-the-boilerplate-code-in-vs-code/
https://code.visualstudio.com/docs/editor/userdefinedsnippets#:~:text=Create%20your%20own%20snippets%23&text=To%20create%20or%20edit%20your,should%20appear%20for%20all%20languages.

for an explanation how to create boilerplates in vs-code. A document like my Replicad quick reference guide (see https://github.com/raydeleu/ReplicadManual/blob/main/replicad-qrc.adoc) could be translated into small snippets of code. Instead of using copy and paste from the quick reference document or typing the code the user can search for a snippet by its name and enter an example piece of code into his/her own code.

There are also some downsides to this approach:

• this only works for the editor for which the snippet library was prepared
• creating snippets is more complicated than cutting and pasting code, especially for long pieces of code
• it only works in environments where you have installed the snippet file
• it relies on the fact that you search for the correct term

[lf94]

For sure there needs to be a global repository for discovery. But even more important is there needs to be established practices of naming for said discovery.

"makeX" should always return a solid.

"sketchX" should always return a sketch.

etc.

I'm really in favor for making all these functions having the same behavior as the main function: first argument object for dependencies, second for shape-specific arguments. This way all shapes are valid replicad models.

I suggest we start by creating a new repository called "RER" (replicad extensions repository) and setting a few moderators which vet incoming code and organize the repository along with other users.

[sgenoud]

My idea would be to rely on the fact that we are using webtechnologies.

Ideally we should be able to import modules share by others directly:

import addYears from "https://unpkg.com/[email protected]/esm/addYears/index.js";

For instance in the case of a module share on npm, or even just a script save in github (or a gist).

This should not be logic that is specific to replicad, but something that uses the (already existing) infrastructure of the web. This make at the same time replicad a better citizen of the web by using its standards, as well as avoiding to limit ourselves to things made in the replicad environment.

I have played a bit with it, but there are a couple of roadblocks so far (some more solvable than others). But this is something definitely worth doing!

[raydeleu]

I think that one of the main benefits of a coded cad solution is that the code is transparent, human readable and re-usable. I noticed this already when I moved from OpenScad to CascadeStudio then to CadQuery and now to Replicad. Sure, the code is slightly different, but the concepts are all the same and to a large degree reusable. For the creation of models I am happy to reuse ideas and even code created by others, the same way I publish my code with all my creations. However, the transparency and reusability becomes lower once it depends on the import of modules, especially when the code of these imported modules is not available. If the library depends on a certain coding environment the user of this library is also tied to this coding environment. Therefore I would favour the approach of creating a repository, providing the option to copy pieces of code, over a solution that depends on importing libraries. Therefore I also fully agree to your statement that we should not limit ourselves to things made in the replicad environment. Software comes and goes, so you should always have an exit strategy.

[sgenoud]

By module I meant javascript modules - a simple way to import code made by other people, but supported by the technology in the browser.

I have played with it and now you can write something like this:

/* global replicad */
/** @typedef { typeof import("replicad") } replicad */

import { makeFlatHinge } from "https://cdn.jsdelivr.net/gh/sgenoud/replicad-hinges@418e11f2a9b712ca4754b889c6847fa750c018c8/main.js";

const { drawRoundedRectangle } = replicad;

export const defaultParams = {
  boxWidth: 120,
  boxHeight: 80,
  boxDepth: 6,
  wallThickness: 1,
};

/** @type {function(typeof defaultParams): any} */
export default async ({ boxWidth, boxHeight, boxDepth, wallThickness }) => {
  const base = drawRoundedRectangle(boxWidth, boxHeight, 5)
    .sketchOnPlane()
    .extrude(wallThickness);

  const top = drawRoundedRectangle(boxWidth, boxHeight, 5)
    .sketchOnPlane()
    .extrude(boxDepth + wallThickness)
    .shell(wallThickness, (f) => f.inPlane("XY", boxDepth + wallThickness));

  const { hinge, hingeWidth } = makeFlatHinge(
    boxDepth + 2 * wallThickness,
    20,
    wallThickness
  );
  return hinge
    .clone()
    .translateX(boxWidth / 4)
    .fuse(hinge.clone().translateX(-boxWidth / 4))
    .fuse(base.clone().translateY(hingeWidth + boxHeight / 2))
    .fuse(base.translateY(hingeWidth + boxHeight / 2))
    .fuse(top.translateY(-hingeWidth - boxHeight / 2));
};

What is different with modules for the visualiser:

• they do not work in Firefox at all
• you can use the gobal object replicad instead of it being passed explicitly to the function
• you can import functions from modules shared online
• the default export of your module is the one used by the visualiser

Why does this encourages code reuse? You can see that I import something from jsdelivr. This is a way to import my code that lives in GitHub (a print-in-place hinge library, still a work in progress but good enough for the current example) that you can find here: https://github.com/sgenoud/replicad-hinges (I need to us jsdelivr to be able to load the code).

Note that I still need to iron out some kinks (and wishes that Firefox supported the technologies need here) and want to have a way to create module that can be imported directly in a script, or shared via npm (for bigger projects).