Skip to content

[Console] Remove restriction for choices to be strings #34790

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

Merged
merged 3 commits into from
Aug 31, 2020
Merged

[Console] Remove restriction for choices to be strings #34790

merged 3 commits into from
Aug 31, 2020

Conversation

LordZardeck
Copy link
Contributor

@LordZardeck LordZardeck commented Dec 3, 2019

Q A
Branch? master
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fix #34789
License MIT

When using choice, selected answers are forced into strings, preventing us from using complex values such as a class with a custom __toString. This is a problem, as I need the ability to present the user with a list of display strings to choose from, but need the ID associated with that display string in order to do anything useful.

@nicolas-grekas nicolas-grekas added this to the next milestone Dec 4, 2019
@nicolas-grekas nicolas-grekas added Feature and removed Bug labels Dec 4, 2019
@nicolas-grekas nicolas-grekas changed the title Remove restriction for choices to be strings [Console] Remove restriction for choices to be strings Dec 15, 2019
@nicolas-grekas
Copy link
Member

Would be worth a test case, can you please add one?

@nicolas-grekas
Copy link
Member

Friendly ping @LordZardeck

@Nyholm
Copy link
Member

Nyholm commented May 3, 2020

I like this.
Thank you.

Could you add a small test case so this can be merged?

@YaFou
Copy link
Contributor

YaFou commented Jul 2, 2020

What is the pull request status? Do you need help?

@fabpot
Copy link
Member

fabpot commented Aug 11, 2020

Anyone willing to take over this PR to finish it? @YaFou perhaps?

@YaFou
Copy link
Contributor

YaFou commented Aug 11, 2020

I'm in vacation but I will finish it later @fabpot. Do I need to open a new pull request?

@fabpot
Copy link
Member

fabpot commented Aug 11, 2020

You can push directly on this PR.

@YaFou
Copy link
Contributor

YaFou commented Aug 23, 2020

@fabpot @Nyholm I opened a pull request LordZardeck/symfony#1 to add a test case for this feature.

@fabpot
Copy link
Member

fabpot commented Aug 23, 2020

I've tried to understand why we have the string cast in the first place. It was added in #14648 as a bug fix. @ogizanagi Can you review and comment on this one as you were the one who wrote the code?

@ogizanagi
Copy link
Contributor

ogizanagi commented Aug 24, 2020

I'm fine for removing this cast.

I think the original fix intended to make selecting choices indexed by keys consistent by always returning strings (it never meant to do it for choices sequentially indexed).
But the true "issue" is an array like ['0' => 'foo', 'foo' => 'bar'] is actually interpreted as [0 => 'foo', 'foo' => 'bar'] by PHP. Which means you can either get '0' or 0 as the value returned by ask depending if you used the key or choice value to answer the question (hence the fix suggestion to always return a string).

A proper fix would have been either:

  • to only cast to string for assoc choices
  • or to properly account for the type of the keys (which is probably not possible actually)

@fabpot
Copy link
Member

fabpot commented Aug 27, 2020

Thanks @ogizanagi. That's clearer to me now. @LordZardeck I think we need to add some test cases to cover the situation explained by @ogizanagi to be sure we don't break anything.

@ogizanagi
Copy link
Contributor

ogizanagi commented Aug 27, 2020

I think we need to add some test cases to cover the situation explained by @ogizanagi to be sure we don't break anything.

These test cases already exist and are failing now, in QuestionHelperTest::testChoiceFromChoicelistWithMixedKeys.

Fixing the code to only cast in the case of assoc choices should solve everything here (we should not forget to get https://github.com/LordZardeck/symfony/pull/1 merged as well in here)

@fabpot
Copy link
Member

fabpot commented Aug 30, 2020

@ogizanagi Would you like to take over?

@ogizanagi
Copy link
Contributor

Sure, I'll update the PR this week

YaFou and others added 2 commits August 31, 2020 15:43
to prevent inconsistency when choosing by key (getting a string as result) or by value (getting an int as result)
@ogizanagi
Copy link
Contributor

@fabpot : Done. But I'm wondering if this should not be merged as a bug fix into 3.4 since the cast was only meant for keys, not for values (int choices values were casted as well). Support for stringable objects just is a consequence of this fix. Let me know, I'll rebase.

Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

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

Looks like a new feature to me. Master is fine :)

@fabpot
Copy link
Member

fabpot commented Aug 31, 2020

Thank you @LordZardeck.

@nicolas-grekas nicolas-grekas modified the milestones: next, 5.2 Oct 5, 2020
@fabpot fabpot mentioned this pull request Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Console choice forces answers as strings
7 participants