You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is example number 8,274,783 why good documentation is needed: Hours after creating this issue, I remembered why LongPrimitive, SymbolPrimitive, etc, exist: they need to inherit from DomainNode which allows for the generic visitor functions like visitDomainNode, and walkDomainNode, etc, which are invoked for every node and leaf in a tree.
Thus, this factoid should be added to the documentation of these types.
Original issue text follows.
We should consider deleting LongPrimitive, SymbolPrimitive and BoolPrimitive and instead use the IonElement equivalent of these: IntElement, SymbolElement and BoolElement.
The existence of these classes doesn't seem terribly justified given that their IonElement equivalents already encompass all of the same functionality. If this were completed then: all we'd need to do to complete #46 is add a few tests, and it would significantly simplify adding support to all of the other Ion types to Kotlin target.
If we discover a better reason than described in the kdoc of these types, and decide instead not do this, then we should include that justification in the explanation given in the kdoc of these classes.
The text was updated successfully, but these errors were encountered:
dlurton
changed the title
Consider using Element interfaces for primitive types
Consider using narrowed IonElement interfaces for primitive types
Jun 13, 2021
dlurton
changed the title
Consider using narrowed IonElement interfaces for primitive types
Justify the existence of LongPrimitive, SymbolPrimitive and BoolPrimitive in their kdoc
Jun 14, 2021
This issue is example number 8,274,783 why good documentation is needed: Hours after creating this issue, I remembered why
LongPrimitive
,SymbolPrimitive
, etc, exist: they need to inherit fromDomainNode
which allows for the generic visitor functions likevisitDomainNode
, andwalkDomainNode
, etc, which are invoked for every node and leaf in a tree.Thus, this factoid should be added to the documentation of these types.
Original issue text follows.
The text was updated successfully, but these errors were encountered: