Old vs. New Workbench Terminology

[gbroques]

Hi all,
As some may know, there's a proposed new style for FreeCAD workbenches documented and proposed by:
https://github.com/FreeCAD/freecad.workbench_starterkit

Are there better terms to describe each style other than "old" vs "new"?

I created an issue on the GitHub repository with more details and a couple of naming suggestions:
https://github.com/FreeCAD/freecad.work ... /issues/13

Naming is important.

It shapes the way people think, so I think it's a topic worth considering.

[vocx]

...
Are there better terms to describe each style other than "old" vs "new"?
...

We have used in the past "namespace workbench" because the workbenches that use this style are installed under a "freecad" directory. Then, ideally, the workbench could import its public functions like

Code: Select all

import freecad.workbench as workbench

workbench.SomeClass()
workbench.some_function()

A problem with the old style is that every module (.py file) that is placed in a Mod/ directory is automatically inside the global namespace, thus the global namespace becomes polluted with various packages, which could also cause clashes with other Python packages provided by the operating sytem. Placing FreeCAD specific modules inside the freecad namespace (in lowercase, following PEP8 guidelines) makes the most sense. So "namespace workbenches".

[gbroques]

... So "namespace workbenches".

Thanks vocx. I like "namespace workbenches" better than "new workbenches".

Updated the GitHub issue thread with that suggestion.

If you call the new style "namespace workbenches", then what would be the contrasting term the for old style, "global namespace polluting workbenches"? lol

Maybe we could call them "scoped workbenches" / "namespaced workbenches" vs. "global workbenches".

[triplus]

Likely we shouldn't bother people with that at all, hence FreeCAD workbench starter kit should do.

[vocx]

Maybe we could call them "scoped workbenches" / "namespaced workbenches" vs. "global workbenches".

Yes, I think global workbench would be the counterpart.

[mnesarco]

... So "namespace workbenches".

Thanks vocx. I like "namespace workbenches" better than "new workbenches".

Updated the GitHub issue thread with that suggestion.

If you call the new style "namespace workbenches", then what would be the contrasting term the for old style, "global namespace polluting workbenches"? lol

Maybe we could call them "scoped workbenches" / "namespaced workbenches" vs. "global workbenches".

I think we should not promote "old style" workbenches, so i propose to name them: Legacy Workbenches.

[vocx]

I think we should not promote "old style" workbenches, so i propose to name them: Legacy Workbenches.

We don't promote them, but we don't have good documentation instructing power users exactly how they should proceed when creating a new workbench. Power users who can do some programming usually copy parts of existing workbenches to write their own, so they copy both good practices and bad practices from them. If somebody asks, I normally tell them to use the namespace workbench style, but it's ultimately up to the user to decide. For example, you took that advice quite well, but I don't think most of the current workbench authors feel very strongly about migrating their code to this new style.

We have this page, Workbench creation, but the namespace workbenches are not mentioned. We should remake the page with updated examples, because the power user needs to follow at least some practical instructions.

In the source code there is an example in src/Mod/TemplatePyMod/. Maybe looo's example workbench-starterkit should be included in a similar directory, src/Mod/TemplatePyNamespace/freecad.new/, or something.

Joel tried to tackle this problem as well. See Workbench-Starterkit refactor.

He wanted to prepare a better template so that new programmers could use it to build their workbenches without many issues. He wanted to separate the structure of a workbench in "tasks", so that every function of a workbench was clearly defined; that follows our philosophy with the structure of Draft and FEM. However, I think Joel didn't proceed further with his investigations due to time constraints (he's been busy with work and his own workbench).

[looo]

Just wanted to say that I am happy with what is going on. namespace-wb/legacy-wb is a good proposal.

[vocx]

Just wanted to say that I am happy with what is going on. namespace-wb/legacy-wb is a good proposal.

Your ideas are good, but we really need to convince active workbench authors (Assembly3, Assembly4, BIM, Dodo, Manipulator, Kicad, etc.) to migrate their code. Otherwise it will be hard to get any traction.

[looo]

Just wanted to say that I am happy with what is going on. namespace-wb/legacy-wb is a good proposal.

Your ideas are good, but we really need to convince active workbench authors (Assembly3, Assembly4, BIM, Dodo, Manipulator, Kicad, etc.) to migrate their code. Otherwise it will be hard to get any traction.

Convincing developers about going for certain conventions is difficult as some might not see the advantages. The original goal was to find an alternative way of handling extensions to get rid of some issues.This is now possible and the list of namespace-packages is growing.

Btw asm3 is already a namespace-wb. That's why we were able to package it with conda and include it in the conda-based bundles.