[ntuple] rename 'leaf' structural role to 'static' #19502
Conversation
jblomer
force-pushed
the
ntuple-rename-leaf
branch
2 times, most recently
from
74816d1 to
b5897c4
Compare
Test Results 21 files 21 suites 3d 6h 7m 47s ⏱️ Results for commit 133130d. ♻️ This comment has been updated with latest results. |
The name 'static field' should better describe the actual structural role of these fields. No change to the on-disk data.
jblomer
force-pushed
the
ntuple-rename-leaf
branch
from
b5897c4 to
133130d
Compare
The structural role "leaf" was ill-named because in the tree of fields also inner nodes can carry that role. Hence renamed to "static". Static nodes are either leaves or they are inner fields with exactly one child field of the same cardinality (modulo field repetition). That is, static fields add hierarchy to the field tree but they don't carry any more structural information.
| | 0x01 | The field is the parent of a collection (e.g., a vector) | | ||
| | 0x02 | The field is the parent of a record (e.g., a struct) | | ||
| | 0x03 | The field is the parent of a variant | | ||
| | 0x04 | The field stores objects serialized with the ROOT streamer | | ||
|
|
||
| A static field is either a leaf or an inner field with exactly one subfield of same cardinality |
There was a problem hiding this comment.
This sentence sounds a bit obscure to me; maybe add an example?
| /// The fields in the RNTuple data model tree can carry different structural information about the type system. | ||
| /// Collection fields have an offset column and subfields with arbitrary cardinality, record fields have no | ||
| /// materialization on the primitive column layer and an arbitrary number of subfields. Static fields are either | ||
| /// leafs (e.g., `float`) or fields with exactly one child that has the same cardinality as the parent | ||
| /// (modulo field repetitions, e.g. std::atomic<T>). |
There was a problem hiding this comment.
I don't 'grasp' the static semantic in this context. To me static field evoke the idea describe here https://en.cppreference.com/w/cpp/language/static.html.
Is the intent to refer to the fact that the cardinality of the element is fixed within the context of its parent/container? eg. Fixed size arrays or single value? Or is it something else.
Leaf was evoking something that could be not further decomposed, for example numerical types and array thereof ... but also technically 'streamer field'.
Can you expand more on the rational of the choice of spelling for kStatic?
There was a problem hiding this comment.
I think the proper semantic association would be with "static array" (as opposed to dynamic array): something with a size known a-priori
There was a problem hiding this comment.
If/since this is the case I think we do need to extend the name to include this notion of size.
There was a problem hiding this comment.
I'm not quite sure how, in this context, the meaning of the C++ static keyword comes to mind.
But I'm not clinging to that name. The currently used leaf is certainly wrong. We also discussed fixed and other.
Concretely, fields of this structural role are either leafs in the schema tree (e.g., float, bool, std::string) or it is an enum field or it is a std::atomic<T> field. For both, enums and atomics, their corresponding field is a wrapper field for the actual data field(s) underneath. My reasoning was that none of leaf fields, enums, and atomics add structural information to the schema tree. I.e., those fields are either leafs or they could be merged with their subfield.
There was a problem hiding this comment.
I'm not quite sure how, in this context, the meaning of the C++ static keyword comes to mind.
Because a field is akin (and often equal) to a data member and thus it can be easily read as 'static data member' ...
No changes to the on-disk format.