[Bug] Inconsistencies in the Expected Format Provider in Converters
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 68/100
Direção de pesquisa
Start with SingleToStringTypeConverter.cs, the double and decimal converter files, and the cited DoubleToStringTypeConverterTests.cs cases. Run ReactiveUI.Binding.Tests under fr-FR and compare the converter comments, behavior, and test expectations across cultures. Decide on consistent culture behavior, then align the converters, comments, and tests; done when the suite passes under the affected cultures.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Prerequisites
- I have searched this repository's open and closed issues for duplicates.
- I am using the latest stable release.
What happens
There are many inconsistencies regarding the expected format provider in converters.
Concretely, SingleToStringTypeConverter indicates that the conversion is performed "using the invariant culture", but only does that for this one case, while other converters for double, decimal, ..., indicate that the conversion is performed "using the current culture".
To make it even more confusing, there are unit tests to verify both behaviors, which is impossible in many cultures. For example, double to string tests have checks expecting both cultures at the same time (TryConvert_WithConversionHint_FormatsCorrectly, TryConvert_NegativeValue_Succeeds).
What is the expected behavior?
What you expected instead
Converters with consistent behavior, comments, and tests.
Minimal reproduction
N/A
Steps to reproduce
- Run
ReactiveUI.Binding.Testsusingfr-FRculture, for example. - Tests fail, and a deeper search through the code base shows all the inconsistencies mentioned above.
Exception and stack trace
Package and version
Latest main (c79c70ccff42edbd97fe7e1dcac6edabc563dd52)
UI framework
None, this is a class library or console app
Operating system
Windows
Target framework
net10.0
Device and OS version
No response
IDE
No response
Did this work in an earlier version?
No response
Workaround
No response
Additional information
No response
- Linguagem predominante
- C#
- Estrelas
- 9
- Forks
- 2
- Merge médio
- 7h 7min
- PRs com merge (30d)
- 75
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de reactiveui/ReactiveUI.Binding.SourceGenerators
-
Dependency DashboardAberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 30/100
reactiveui/ReactiveUI.Binding.SourceGenerators#3 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de reactiveui/ReactiveUI.Binding.SourceGenerators
Issues semelhantes
-
clawsweeper:source-repro impact:ux-release-blocker issue-rating: 🦞 diamond lobster P0
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
openclaw/openclaw-windows-node#1723 · 1 comentário · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
good first issue hacktoberfest help wanted new-language
Dificuldade 2/5 Meio dia Facilidade para iniciantes 78/100
-
[Android] Controls.DeviceTests build fails with xUnit2031 analyzer errorTalvez já em andamento @HarishwaranVijayakumar assumiu hoje. Abertapartner/syncfusion s/triaged s/verified
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
dotnet/maui#39376 · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
documentation
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 62/100
-
bug misleading tooling trivial
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
Mantenedores costumam responder em até 1 dia