buildingSMART / buildingSMART/IFC4.x-development
Should IfcSegmentedReferenceCurve be a subtype of IfcGradientCurve?
- Dominant language
- Python
- Stars
- 234
- Forks
- 123
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 5
Description
This is a bit of a minor thing, but should IfcSegmentedReferenceCurve be a subtype of IfcGradientCurve? It's a backwards compatible change to make.
It would make things more consistent, and glancing at the code we have on our end now, it would have minimally simplified things.
```
IfcCompositeCurve
^
|
IfcGradientCurve
^
|
IfcSegmentedReferenceCurve
```
(In general I'm not too fond of geometric items inheriting from each other. For example we had IfcAsymmetricIShapeProfileDef previously inheriting from IfcIShapeProfileDef, which in my point of view violates liskov substitutability, and can result into unnoticed omissions in implementations where an IfcAsymmetricIShapeProfileDef is silently handled as a IfcIShapeProfileDef.
IfcBoxedHalfSpace is an example, where it is valid, where every IfcBoxedHalfSpace functionally performs the same as an IfcHalfSpaceSolid.)
Contributor guide
Research direction
Start by reviewing the IFC4.x specification definitions for IfcCompositeCurve, IfcGradientCurve, and IfcSegmentedReferenceCurve, then compare the inheritance examples discussed in the issue. Determine whether the proposed subtype relationship preserves the intended semantics and backward compatibility. Done means reaching a documented decision on the inheritance change.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100