Shall we expose toolkit-specific Ids through ToolkitId methods?

[pawelbaran]

Following the discussion in BHoM/BHoM_Adapter#288, I believe that adding toolkit-specific Query methods returning toolkit-specific Ids would be an easy yet nice UX booster - the currently available generic AdapterId method is hard to capture for non-expert users who do not know what AdapterIdFragmentType is. Therefore, I think we should add methods like RobotId, EtabsId etc. that would simply call AdapterId. Looks like we have an initial agreement on that, but just to confirm, what do you think?

[IsakNaslundBh]

Happy to get this added from my end

[al-fisher]

Agreed

[alelom]

As I stated here, I'm more than happy with this.

[pawelbaran]

Cool, how would you name the method? AdapterNameId? Or without adapter name prefix, taken into account it can be deducted from the namespace?

[alelom]

I think I'd go for RobotID, RevitID, EnergyPlusID, etc.
(note the all caps ID as @FraserGreenroyd likes)

[pawelbaran]

In Revit_Toolkit we have ElementId, which is named after the Revit concept - I believe it is worth keeping it not to confuse the users, but on top of it I can add an identical method named RevitID to align to the proposal. Would anyone be against such duplication?