Change Adapter oM and Engine namespaces to `Adapters`

[alelom]

Description

See the general issue text below.

Action required

The repos that need attention are all Toolkits that include an Adapter project.

• https://github.com/BHoM/3DRepo_Toolkit (not in installer) @alelom
• https://github.com/BHoM/DIALux_Toolkit
• https://github.com/BHoM/EnergyPlus_Toolkit (not in installer)
• https://github.com/BHoM/HTTP_Toolkit
• https://github.com/BHoM/IES_Toolkit
• https://github.com/BHoM/Lusas_Toolkit @peterjamesnugent PR
• https://github.com/BHoM/MidasCivil_Toolkit @peterjamesnugent PR
• https://github.com/BHoM/Mongo_Toolkit
• https://github.com/BHoM/OpenStudio_Toolkit (not in installer)
• https://github.com/BHoM/OpenStreetMap_Toolkit
• https://github.com/BHoM/RAM_Toolkit no action needed
• https://github.com/BHoM/Revit_Toolkit @pawelbaran (I think this is Revit_Toolkit: Clean up namespace/assembly names Revit_Toolkit#517)
• https://github.com/BHoM/RFEM_Toolkit Remove reference and usings pointing to Common_oM and update namespace RFEM5_Toolkit#86
• https://github.com/BHoM/Robot_Toolkit Update namespace for some engine methods Robot_Toolkit#380
• https://github.com/BHoM/ETABS_Toolkit Change namespace to BH.Engine.Adapters.ETABS ETABS_Toolkit#319
• https://github.com/BHoM/GSA_Toolkit Update namespace of oM and Engine GSA_Toolkit#179
• https://github.com/BHoM/SAP2000_Toolkit
• https://github.com/BHoM/S-Frame_Toolkit (not in installer)
• https://github.com/BHoM/Socket_Toolkit
• https://github.com/BHoM/Speckle_Toolkit (not in installer) @alelom
• https://github.com/BHoM/TAS_Toolkit
• https://github.com/BHoM/TeklaStructuralDesigner_Toolkit
• https://github.com/BHoM/XML_Toolkit @FraserGreenroyd PR

[alelom]

Description

We want the menu items for Engine and oM classes defined in Adapter-Based-Toolkits (= only Toolkits that contain an Adapter project) into a new category, Adapters.

This is mainly to tidy up the menu items, to avoid clutter, and leaving the base Engine methods and classes on the top level.

Currently we have this situation:

What we want is:

This means:

1. Take note of all changes you will be doing at the following points.
2. Add the Adapters name to the namespace of all your oM and Engine classes.
3. This last point applies only for some Toolkits such as Lusas and Revit in the first picture above. Check if you have:
   • BH.oM.Adapter.something have to become BH.oM.Adapters.something (note the s);
   • BH.oM.External.something have to become BH.oM.Adapters.something.
   • BH.oM.Adapters.something do not change them.
   • BH.Engine.Adaper.something have to become BH.Engine.Adapters.something (note the s);
   • BH.Engine.External.something have to become BH.oM.Adapters.something.
   • BH.Engine.Adapers.something do not change them.

You must take note of what changes you've applied and list them in your PR.

E.g.

• All classes that were originally under BH.oM.SAP2000 are now into BH.oM.Adapers.SAP2000
• All classes that were originally under BH.Engine.SAP2000 are now into BH.Engine.Adapers.SAP2000
• All classes that were originally under BH.oM.Adapter.SAP2000 are now into BH.oM.Adapers.SAP2000 (note the s)
• All classes that were originally under BH.oM.External.SAP2000 (note the s) are now in BH.oM.Adapers.SAP2000

this will be used to inform the Versioning_Toolkit and make sure we get retro-compatibility for this change.

IMPORTANT NOTE

Note that the following usings:

using BH.oM.Adapter;
using BH.oM.Adapter.Commands;

using BH.Engine.Adapter;

using BH.Adapter.Modules.Structure

are not to be changed as they refer to the base Adapter namespace, which is not the subject of the current renaming.

[alelom]

After last chat with @al-fisher

We decided to bump this as a priority in 3.2

Reason is, to get best compromise between the benefit of the renaming and the actual amount of work, we thought it's best to properly change all existing Adapter-based-Toolkits.

I'm including updated instructions above. I've tried to be as clear as possible. Let me know what you think.
@FraserGreenroyd @IsakNaslundBh

[rwemay]

Apart from the vote for BH.oM.Adapters (plural), I'm just going to throw one final curved ball in there - BH.oM.Adaptation.

[IsakNaslundBh]

My vote goes to BH.oM.Adapters

[epignatelli]

I also updated the wiki for the External class to specify what that is about:
https://github.com/BHoM/documentation/wiki/BHoM_Engine-Classes/

My vote goes to Adaptation.

[alelom]

Everyone,
thanks for the nice chat!

To recap:

• We agreed that External as a name is more suited for @epignatelli 's use case. His use case didn't exist when we originally had agreed on that name here. To avoid confusion, we had to reconsider other options.
• I proposed Toolkit instead, but there was general consensus against this – @al-fisher clearly formulated how this would go against BHoM principles
• We ended up back on considering Adapter, but again with no consensus, mainly because that creates confusion: having BH.oM.Adapter / BH.Engine.Adapter is confusing for people less familiar with the framework ("are the classes in those namespaces actually contained in the Adapter project or in a oM or Engine project")?
• After some conversation we went back considering Adapters (with an s) to distinguish namespaces from the actual project. Resulting proposal: BH.oM.Adapters / BH.Engine.Adapters
• @alelom, @rwemay and @epignatelli still were not very convinced – more distinction from the Adapter project was perceived as needed
• @rwemay proposed Adaptation as a candidate. Resulting proposal: BH.oM.Adaptation / BH.Engine.Adaptation

We'd like everyone to express their preference between the 2 remaining proposals in this survey:
https://www.surveymonkey.co.uk/r/BHGQYX3

Thanks!

[pawelbaran]

True democracy!

[rwemay]

:) I bottled it and went with my initial instinct of adapters plural. Looks like adapters wins?! Let’s reserve adaptation for truly chameleon like behaviours!

[alelom]

Official results for the joy of democratation 😄