openhab-core
openhab-core copied to clipboard
Extend OnOffType so it can be used as drop-in-replacement for Number types
I have added the methods of java class Number
to OnOffType
. This allows items of this class to be used as drop-on-replacement for numeric types in scripted rules:
if (ir.getItem("someItem").getState().intValue() > 0) { .... }
Additionally, I have added a method booleanValue()
, which allows this state to be used without importing OnOffType first.
It's less code and easier to understand if you just use a static import for OnOffType.ON
:
if (ir.getItem("someItem").getState() == ON) {
It's less code and easier to understand if you just use a static import for
OnOffType.ON
:
if (ir.getItem("someItem").getState() == ON) {
Yes, but this is not what the patch intended in the first place. The patch allows to replace an Number item with a Boolean item without breaking existing rules.
OnOffType is also used in add-on code and tests. Adding these options will probably result in contributors using the type in the wrong way and maintainers having to add review comments for this.
which allows this state to be used without importing OnOffType first.
Where do you need to import OnOffType in rules? It's imported by default in Rules DSL. jRuby I think provides a wrapper. JS Scripting always returns the state of Items as a String unless otherwise indicated. I don't know about Groovy. Is this actually solving a real problem or a perceived problem in rules.
If it's a real problem, maybe the place to correct it is in the helper library for the language instead of in core where, as @wborn points out, it could have more knock on effects than the improvement is worth.
Wouldn't it make more sense to add a getStateAs()
method than all of these new methods? That would be consistent with other Types like DimmerType, ColorType, etc.
At a minimum I would expect to see just one toNumber()
method. It's left to the caller to pull the primitive from the Number
. Everywhere else a number appears in the OH API as seen from rules, when there's a number OH presents it as a Number
, not a primitive. Consistency is important.
Also, what about ContactType?