[Unity3d 4.6 beta 18] Suggestion Change UI.Toggle.isOn property to UI.Toggle.toggleState

UPDATE: Senshi suggested UI.Toggle.toggleState, which is better than my original suggestion.


I was attempting to turn a UI.Toggle on after loading my PlayerPrefs. For a day, I could not find the answer due to a poorly named property.. and my not reading every character of the documentation =)

My question was essentially:
Does anyone know how to tell a UI.Toggle to become active in code?

Answer:
Set the UI.Toggle.isOn property to true. I bypassed the property due to assuming that it was a function that returned a bool; like EventSystems.UIBehaviour.IsActive or UI.Selectable.IsInteractable.

At this time the documentation for the UI.Toggle.isOn call is:

> Is the toggle on.

This sounds like a method that returns a bool, but when you click through it is clearly referenced as an actual bool property. Maybe a better label could be used to identify it as an actual value. Like 'UI.Toggle.toggleState' which would be like the enabled property on many Unity objects.

After looking for instances of properties and methods starting with 'is' in the scripting reference, there appears to be no standard usage of the word 'is' in naming. The word 'on' for example has the standard usage of being a method that reacts to an event. I would also advise enforcing some standard naming practices in the future. I realize that Unity is too far along to correct past issues and break everyone's code.

Unity Answers question that I both asked and answered:
http://answers.unity3d.com/answers/782433/view.html

Unity Feedback post:
http://feedback.unity3d.com/suggest...t-ison-property-to-ui-dot-toggle-dot-selected

 

I added parentheses when using it the first time. I thought MonoDevelop had screwed up again! It's just one of many inconsistencies in the naming of variables/methods, and the types used.

 

Agreed on the inconsistencies. I wish they would refactor the names when they go to Unity 5. This would be the perfect time as everyone would have to upgrade their projects. The new names could be handled during the upgrade of an old project. There would be some initial shell shock for devs, but we would adapt quickly.

I foresee them doing this eventually... I am just wondering when they are going to pull the trigger. If they need a fall guy, they can hire me as a Software Engineering Consultant and blame me =)

 

I agree there might be a bettter name for this (though Unity *is* consistent in naming (only) all methods with a capital letter). As for "selected", this might be easily confused with Selectables, SelectionState, etc., so I would propose something like state/ toggleState. +1 from me though!

 

UI.Toggle.toggleState as a bool property works fine with me. Clean and descriptive. I wouldn't have wasted time on looking around with that name.

 

Isn't Toggle.toggleState redundant? That's like naming velocity on rigidbody to Rigidbody.rigidbodyVelocity. It's just Rigidbody.velcoity.

 

I wouldn't fault them for using UI.Toggle.state. Although, I might say the word 'state' is a bit too general for a customer facing API. UI.Toggle.toggleState is more explicit and leaves no question as to what it controls.

 

Or maybe match Slider and call it UI.Toggle.value?

 

The problem in Unity is that you can find precedents for all of these options =)

Again, I wouldn't fault them for using UI.Toggle.value, but still stick with UI.Toggle.toggleState.

 

I glad that I'm not crazy and people actually think it should be changed from the current UI.Toggle.isOn.

 

Haha, I'm actually fine with on or isOn. It mimics apples UISwitch class.

 

They're already using active and enabled so state does seem like the next best thing. Calling it toggleState not only sounds redundant but also sounds like a function to toggle it's own state. Although it can't be confused with a function if you know proper naming conventions.

+1 Toggle.state

Alternatively they could change it to Toggle.toggle just as I use Health.health for my health script(s).