Closed alelom closed 1 year ago
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:
Adapters
name to the namespace of all your oM and Engine classes.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.E.g.
BH.oM.SAP2000
are now into BH.oM.Adapers.SAP2000
BH.Engine.SAP2000
are now into BH.Engine.Adapers.SAP2000
BH.oM.Adapter.SAP2000
are now into BH.oM.Adapers.SAP2000
(note the s
) 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.
Note that the following using
s:
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.
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
Apart from the vote for BH.oM.Adapters
(plural), I'm just going to throw one final curved ball in there - BH.oM.Adaptation
.
My vote goes to BH.oM.Adapters
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
.
Everyone, thanks for the nice chat!
To recap:
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.Toolkit
instead, but there was general consensus against this – @al-fisher clearly formulated how this would go against BHoM principlesAdapter
, 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")?Adapters
(with an s
) to distinguish namespaces from the actual project. Resulting proposal: BH.oM.Adapters
/ BH.Engine.Adapters
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!
True democracy!
:) 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!
Official results for the joy of democratation 😄
Updated issue title and instructions.
Can I confirm that this is now the absolute latest version that we're going with? Cause XML Toolkit has already changed to External and will now need updating again, and MidasCivil/Lusas have gone to External by @peterjamesnugent and will presumably also need updating - so would like to avoid making the change again if the decision is not concrete? Definitely BH.Engine.Adapters.Blah
for anything we don't want exposed in UIs?
Hitting up @FraserGreenroyd's query - happy to action but could we please confirm we all are aligned?
@pawelbaran I've already made the changes on MidasCivil and Lusas.
Changes to External
or Adapters
?
Adapters
Yes - can confirm Adapters
is agreed namespace following all discussions
@alelom
Yes it is Adapters
.
Closing as completed.
Description
See the general issue text below.
Action required
The repos that need attention are all Toolkits that include an Adapter project.