Checked renamed State in CheckBox

[tznind]

Checked renamed State in CheckBox

[tig]

I love good debate! Thanks for engaging guys. Makes us all better.

[tig]

I dunno, the API docs make it pretty clear:
https://gui-cs.github.io/Terminal.GuiV2Docs/api/Terminal.Gui.CheckBox.html

What @tznind is asking for is using a name where exist the previous changed property to be much more easy to find in search property helping the replacing from the older property to the new. If the older property was named Checked then rename it to ChechedState or CheckState is much more easy to find and replace.

And if we did this, then would you expect all of these to start with "TableView"?

No, because we are not talking the same thing. If some of this properties is changed with another type with a "State" on the name then the logic change will be {OldPorpertyName}State.

If we apply this concept to every API we've changed from v1 to v2 we'd end up with a v2 API surface area with tons of really long, non-terse, names.

I understand the frustration, but we are building for the future. We have migratingfromv1.md and vastly improved API docs. Etc...

(Yes, I know that I failed to put this in migratingfrom v1.md).

[tznind]

It's your call.

All I can do is describe my experience.

I first searched for Checked then IsChecked then I saw the Toggled event so I looked for a Toggled property - no joy. I even looked at the list of public properties and State did not jump out at me. I had to go to source.

Maybe I was tired or not paying enough attention or i mentally lump State in with other 'meta things' like Style and Focused. If you think it is fine then leave it.

DateView property is called Date
ColorPicker is called SelectedColor
FileView is called SelectedFile

They are not just called Selected.

[tig]

LMK what you think of this: #3648

[tig]

As an enum vs. bool? Checked made zero sense. So it needed to be renamed. I applied two principles when deciding to rename it State.

1. Terseness. Names should be as terse as possible. The View is named CheckBox. Naming a property CheckState is duplicatlve.
2. Consistency. If a View has a "state", it's "state" should be named "State".

Happy to change it to CheckState if you really think I went too far though.

[BDisp]

As an enum vs. bool? Checked made zero sense. So it needed to be renamed. I applied two principles when deciding to rename it State.

1. Terseness. Names should be as terse as possible. The View is named CheckBox. Naming a property CheckState is duplicatlve.

But the suggested name CheckedState doesn't come from the CheckBox but from the old property name Checked. So, in my opinion make sense.

2. Consistency. If a View has a "state", it's "state" should be named "State".

But a View by itself doesn't expose a "state" but through a property and the resulted name must be the join of "[Property]State".

Happy to change it to CheckState if you really think I went too far though.

Only expression my opinion for not use only the name "State" on all View subclasses. If that is the intention then the View class must have a "State" property but that will be a bad idea because the "State" would have different types on all derived views.

[tznind]

@tig I can see the reasoning, but Checkbox is also a View so from an autocomple drop down of properties State could easily be some View related thing or core concept (especially if you don't know the library). I get it's in bold and the Type makes it obvious once you have found it but still. I think starting with prefix Check i.e. CheckState will make it easier to find and crystal clear.

[tig]

@tig I can see the reasoning, but Checkbox is also a View so from an autocomple drop down of properties State could easily be some View related thing or core concept (especially if you don't know the library). I get it's in bold and the Type makes it obvious once you have found it but still. I think starting with prefix Check i.e. CheckState will make it easier to find and crystal clear.

I dunno, the API docs make it pretty clear:

https://gui-cs.github.io/Terminal.GuiV2Docs/api/Terminal.Gui.CheckBox.html

And if we did this, then would you expect all of these to start with "TableView"?

[BDisp]

I dunno, the API docs make it pretty clear:

https://gui-cs.github.io/Terminal.GuiV2Docs/api/Terminal.Gui.CheckBox.html

What @tznind is asking for is using a name where exist the previous changed property to be much more easy to find in search property helping the replacing from the older property to the new. If the older property was named Checked then rename it to ChechedState or CheckState is much more easy to find and replace.

And if we did this, then would you expect all of these to start with "TableView"?

No, because we are not talking the same thing. If some of this properties is changed with another type with a "State" on the name then the logic change will be {OldPorpertyName}State.

[BDisp]

I understand that @tig already took a long time to preparing the migratingfrom v1.md and others documents, but as he like to say in the v2 until the beta version it's possible to make considerable changes and thus also changing the doc in the v1 version related to this.
Each derived class has his own default property (the bold on) and doesn't to have the same name of each other, like @tznind said. @tig you also are very insistent with us and you already know mw the sufficient that I also talk when I think I've reason but also I also beg apologize when I was wrong. So, if you really end up that we have reason then you may could make the changes, otherwise leave as is and from my part I'll never talk more about this.