Closed pawelbaran closed 1 month ago
@BHoMBot check compliance
@BHoMBot check compliance
Sorry, I just saw in another context that you wanted to "ditch naming Unit Type and Display Unit Type altogether". While DisplayUnitType
should go, the latest Revit API still has UnitTypeId
so I guess we can still use the term UnitType
where it makes sense.
Sorry, I just saw in another context that you wanted to "ditch naming Unit Type and Display Unit Type altogether". While
DisplayUnitType
should go, the latest Revit API still hasUnitTypeId
so I guess we can still use the termUnitType
where it makes sense.
The problem is that the old DisplayUnitType
is correspondent to UnitTypeId
, while UnitType
can be taken from SpecTypeId
class. So, besides renaming stuff, Autodesk also managed to reuse the old concept of 'Unit Type' in the new context 🤯 This is why I got so much into 'Spec' and 'Unit' to avoid ambiguity with the old times.
The problem is that the old
DisplayUnitType
is correspondent toUnitTypeId
, whileUnitType
can be taken fromSpecTypeId
class. So, besides renaming stuff, Autodesk also managed to reuse the old concept of 'Unit Type' in the new context
I think we should only consider the new system going forward, as DisplayUnitType
can be removed from our code within a year, while being descriptive on the methods can make them more useful for a long time 👍
All my comments are for the same idea of making the return types more explicit. I actually find the Revit API's new unit classes very confusing so this would help me in using these methods in the future. Future devs can benefit too 👍
Thanks for so much thought put into the comments - indeed, the new system is so confusing. I can see that you suggest adding Type
suffix to specs and units. Not sure, however, if these are needed actually- according to Revit API documentation SpecTypeId
class contains constants identifying specs, i.e. the base concept is Spec
, TypeId
being noise added to name the class in a complex way 🙈 So what I am trying to do is demistyfying the whole thing and simplifying it to Spec and Unit.
Another thing that I tried to achieve with chosen naming was coupling to and from: SpecName
query to get the name from a spec, coupled with SpecFromName
to get the spec from its name. With your suggestion, we lose this coupling, which I think is worth keeping.
What do you think?
Yes, let's keep your naming system. It's definitely better 👍
@BHoMBot check core @BHoMBot check serialisation @BHoMBot check null-handling
@BHoMBot check installer
@BHoMBot check ready-to-merge
Issues addressed by this PR
Closes #
Test files
Changelog
UnitTypeFromPropertyName
toSpecFromName
andUnitTypePropertyName
toSpecName
UnitName
andUnitFromName
Additional comments