Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Columns_To_Add type to move away from Integer | Nothing #10152

Merged
merged 19 commits into from
Jun 4, 2024

Conversation

marthasharkey
Copy link
Contributor

@marthasharkey marthasharkey commented Jun 3, 2024

Pull Request Description

Adds new type "Coulmns_To_Add" that replaces the Integer | Nothing type
And adds new widget to split_to_columns and tokenise_to_columns
image

Closes #10041

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.

@marthasharkey marthasharkey added the CI: No changelog needed Do not require a changelog entry for this PR. label Jun 3, 2024
@marthasharkey marthasharkey changed the title Wip/mk/add column count type Add Columns_To_Add type to move away from Integer | Nothing Jun 3, 2024
@marthasharkey marthasharkey marked this pull request as ready for review June 3, 2024 13:29

## PRIVATE
type Columns_To_Add
## Read all rows.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doc comment seems off.

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just some small nits

_ = [column, delimiter, column_count, on_problems]
@column_count Columns_To_Add.default_widget
split_to_columns : Text | Integer -> Text -> Columns_To_Add -> Problem_Behavior -> DB_Table
split_to_columns self column delimiter="," (column_count : Columns_To_Add = ..All_Columns) on_problems=Report_Warning =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update the Arguments: documentation above for column_count, here, and in the other related spots.

@@ -22,11 +23,11 @@ polyglot java import org.enso.table.data.mask.OrderMask
- input_column: The column to transform.
- function: A function that transforms a single element of `input_column`
to multiple values.
fan_out_to_columns : Table -> Text | Integer -> (Any -> Vector Any) -> Integer | Nothing -> (Integer -> Any) -> Problem_Behavior -> Table | Nothing
fan_out_to_columns table input_column_id function column_count=Nothing column_builder=make_string_builder on_problems=Report_Error =
fan_out_to_columns : Table -> Text | Integer -> (Any -> Vector Any) -> Columns_To_Add -> (Integer -> Any) -> Problem_Behavior -> Table | Nothing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add argument documentation for column_count.

@@ -204,7 +205,7 @@ add_specs suite_builder =
t = Table.new cols
expected_rows = [[0, "a", "c", Nothing, Nothing], [1, "c", "d", "ef", Nothing], [2, "gh", "ij", "u", Nothing]]
expected = Table.from_rows ["foo", "bar 1", "bar 2", "bar 3", "bar 3"] expected_rows
t2 = t.split_to_columns "bar" "b" column_count=4
t2 = t.split_to_columns "bar" "b" column_count=(Columns_To_Add.First 4)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the old behaviour still work? I think that it should and we should leave the test in place to ensure that it does

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old behaviour will still work as we have conversion from Integer to Columns_To_Add.
We should keep a test proving this.

Copy link
Member

@AdRiley AdRiley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I just have a question of whether this should be a breaking API change for existing workflows?

Copy link
Member

@jdunkerley jdunkerley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few little tweaks but looks good.

@@ -39,6 +39,7 @@ import Standard.Table.Internal.Widget_Helpers
import Standard.Table.Match_Columns as Match_Columns_Helpers
import Standard.Table.Row.Row
import Standard.Table.Rows_To_Read.Rows_To_Read
import Standard.Table.Columns_To_Add.Columns_To_Add
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nit but please put in alphabetical order

@@ -7,6 +7,7 @@ import project.Conversions.Convertible_To_Rows.Key_Value
import project.Internal.Problem_Builder.Problem_Builder
import project.Table.Table
import project.Value_Type.Value_Type
import project.Columns_To_Add.Columns_To_Add
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above please sort alphabetically.

@jdunkerley
Copy link
Member

Looks good. I just have a question of whether this should be a breaking API change for existing workflows?

Don't believe we have a breaking API change. Happy path is unchanged, though unhappy path now a warning not an error but think this is ok.

@AdRiley
Copy link
Member

AdRiley commented Jun 3, 2024

Looks good. I just have a question of whether this should be a breaking API change for existing workflows?

Don't believe we have a breaking API change. Happy path is unchanged, though unhappy path now a warning not an error but think this is ok.

My question is can you pass Nothing and an Integer into this parameter as you could before? And should you be able to?

@jdunkerley
Copy link
Member

Looks good. I just have a question of whether this should be a breaking API change for existing workflows?

Don't believe we have a breaking API change. Happy path is unchanged, though unhappy path now a warning not an error but think this is ok.

My question is can you pass Nothing and an Integer into this parameter as you could before? And should you be able to?

Yes you can (as the auto conversion will be fired).

This is the same as when I change read to take an Rows_To_Read. It still allows backwards compatibility and plays nicely with the widgets. Plus I think the more text friendly .split_to_columns "input" column_count=3 is still a useful shorthand.

@jdunkerley jdunkerley added the CI: Ready to merge This PR is eligible for automatic merge label Jun 4, 2024
@mergify mergify bot merged commit 24d209a into develop Jun 4, 2024
37 checks passed
@mergify mergify bot deleted the wip/mk/add-column-count-type branch June 4, 2024 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove the use of Integer | Nothing for column_count argument.
5 participants