Not more than 3 arguments possible for procedures

Setup, Configuration and Use Migration
1

After updating to 4.3.1 procedures in rules with more than 3 arguments seem not anymore possible:

The following declaration:

val dht22_filter1 = [ 
    GenericItem raw_item, GenericItem filtered_item, Map<String, Double> limits, Double offset |
    
]

results in an error:

[el.core.internal.ModelRepositoryImpl] - Configuration model ‘dht22.rules’ has errors, therefore ignoring it: [39,25]: mismatched input ‘,’ expecting ‘]’

If the last argument is removed it will work.
In 4.1. it was working with 5 arguments with the old Syntax:

val Procedures$Procedure5<GenericItem,GenericItem,Map<String, Double>,Double,Map<String, Double> > dht22_filter= [ 
    GenericItem raw_item,
    GenericItem filtered_item,
    Map<String, Double> limits,
    Double offset,
    Map<String, Double> last_values |

Is this is a bug or I’m doing something wrong?

Thanks a lot
Karsten

2

I imagine it’s possible they lowered the limit from 7 to 3. that would have been done upstream in the Xtend project. Xtend was indeed upgraded in 4.2.

However, I just looked at the latest code there and they still support up to 6 arguments.

Have you imported Map?

I don’t see anything wrong per se except for the fact that with the “new” declaration (which really isn’t new, it was always supported even back in 1.x) whether it treats it as a Function or a Procedure depends on the output of the last line (or lines if you have branching logic) executed in the code. It that last line returns anything but void it’s going to define dht22_filter1 as a Function instead of a Procedure (the difference between the two is Procedures do not return anything).

I’m not sure that matters at all but it’s soemthing to note. For something named “filter” I would have expected a return value. :man_shrugging:

What is interesting is the error is comming from column 25.

                        |
    GenericItem raw_item, Ge

That’s the comma after the first argument. I’m assuming the arguments are on line 39. I’m not sure what that means but it’s another data point.

Since this worked before and doesn’t now you’ll probably need to file an issue. But it’s stuff like this which makes me recommend against new development of rules using Rules DSL. Any of the other options are better than Rules DSL these days (more complete access to the OH APIs, support for real functions, classes, and libraries, actively supported, helper libraries to insulate you from changes in core like the deprecation of toZonedDateTime on DateTimeType that came with 4.3). That advice doesn’t necessarily apply here as this isn’t new development, but it’s something to consider. Maybe experiment with the other options and see if it makes sense to port this rule to a different language as a work around.

If this is a bug or regression, there is no telling when/if it’ll get fixed. Xtend is notoriously difficult to work with.

3

Thanks a lot for the quick answer. The code relatively old. I found a workaround - I removed the procedure.

I imported:
import java.util.Map
import org.eclipse.xtext.xbase.lib.Procedures

But there was no difference wheter I imported Procedures or not.

Thanks a lot
Karsten