Add KDocs for non-deprecated `toDataFrame` / `toDataFrameFromPairs` APIs
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 1.1k
- Forks
- 83
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 30
Description
Add KDocs for non-deprecated toDataFrame / toDataFrameFromPairs APIs
The file core/src/main/kotlin/org/jetbrains/kotlinx/dataframe/api/toDataFrame.kt holds the public toDataFrame / toDataFrameFromPairs conversion APIs and their supporting DSL. It contains many overloads; almost none are documented (only List<List<T>>.toDataFrame(header, containsColumns) and a few TraversePropertiesDsl members have KDocs).
Please add concise KDocs for the current non-deprecated APIs only. Deprecated and binary-compatibility (@AccessApiOverload) overloads are out of scope.
Scope — main semantic blocks
- From objects (reflection-based) —
Iterable<T>.toDataFrame()and its variants (theCreateDataFrameDslbodyoverload, thevararg props/maxDepthoverload, and the single-columnNameoverload). These turn each object into a row by reading its properties. - From rows / columns / maps —
Iterable<DataRow>,Iterable<BaseColumn>,Iterable<Map<String, Any?>>, and theMap<String, Iterable>/Map<ColumnPath, Iterable>overloads. - From pairs (
toDataFrameFromPairs) — theColumnPath/String→ column/values overloads that build (possibly nested) column groups from path→column pairs. - From lists of lists —
List<List<T>>.toDataFrame(header, containsColumns)(already documented; keep/align). - The building DSL — the
CreateDataFrameDslclass and its members (add,expr,into,from,inferType,String.invoke,properties), theTraversePropertiesDsl(exclude/preserve, partly documented already), and theValuePropertyschema interface.
KDocs should explain
- At the block level, what the conversion produces: how source elements map to rows vs columns, and how nested structures become column groups (especially for the property-reflection and
toDataFrameFromPairsblocks). - For the reflection block: that columns are derived from properties, the meaning of
maxDepth(recursion depth for nested objects) andprops(explicit property roots), and how theCreateDataFrameDsllets users add/rename/compute columns. - For
TraversePropertiesDsl:exclude(skip classes/properties during traversal) andpreserve(keep a type as aValueColumninstead of expanding it) — extend the existing short KDocs into full ones. - For
toDataFrameFromPairs: how column paths with size > 1 are grouped into nestedColumnGroups, and that duplicate top-level names are made unique. - Column name generation / uniqueness and type inference (
createByInference/createColumnGuessingType) where relevant. - The difference between
toDataFrameandtoDataFrameFromPairs(the latter takes explicit path→column pairs and is the nesting-aware builder).
Acceptance criteria
- Every public, non-deprecated
toDataFrame/toDataFrameFromPairsoverload is covered by a KDoc, grouped by the semantic blocks above. - The
CreateDataFrameDsl,TraversePropertiesDsl, andValuePropertypublic types and their non-deprecated members are documented; the existingexclude/preserve/List<List<T>>.toDataFrameKDocs are kept or expanded, not removed. - No documentation is added for deprecated /
@AccessApiOverloadoverloads. - KDocs make clear how source shapes map to rows/columns and how nesting (column groups) is produced.
- Docs are consistent with the site docs at
createDataFrame.html.
Related to the #1479
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with core/src/main/kotlin/org/jetbrains/kotlinx/dataframe/api/toDataFrame.kt and compare its public non-deprecated APIs with the createDataFrame.html site documentation. Review the existing KDocs and semantic blocks, then document the specified overloads and DSL members, including source-to-row/column mapping, nesting, inference, uniqueness, and traversal behavior without covering deprecated or @AccessApiOverload APIs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100