1

If you define a DSL file with some lines, and one of them uses a variable, you cannot use it twice in a rule because you will get a duplicate variable error.

What's the best way to avoid this? Ideally I would like to avoid to create two copies of the DSL line to just change the variable name.

ie, the DSL line:

[when][]For all qualifications of type Higher=$highers: Higher()

this cannot be used twice in the same rule or we get a duplicate $highers variable.

Francesco
  • 857
  • 1
  • 11
  • 26
  • Why do you have to use the same rule twice? What are you trying to achieve? – kaskelotti Jan 23 '15 at 03:12
  • well it's a DSL definition (one line of it), so it can be used in a rule. In this rule I want to describe more than one thing needs to happen in order to fire, and to describe these things, I would like to reuse the same DSL line twice. I think it's a valid scenario. – Francesco Jan 23 '15 at 13:30
  • Whether it's DSL is irrelevant. You need to think what DRL is being generated. Following your chain of thought, you are trying to create two different variables with the same name. How do you imagine that to be a valid piece of code? Also, how would writing the same clause twice be useful? In the example you provide above, you have already bound a `Higher()` to `$highers`. Why would repeatedly binding a value to the same variable be useful? – Steve Jan 23 '15 at 15:18
  • ok maybe the example I made is misleading, I was trying to find an easy one. But there are cases where you want to use the same line twice, that I know will lead into a duplicated variable name, that I know is bad, but I would like to find an elegant solution to this. I'll post a better example. – Francesco Jan 23 '15 at 17:58
  • Here's a better example: `[when][]there is a qualification of type {qualification}=$qualification: {qualification}() [when][]- with {field} {operator} {value}={field} {operator} {value}` I can use this line to get every type of qualification, but it will be possibile to use it just once in the same rule. For example, this is a sensible rule that cannot be written because will cause a duplicate $qualification variable: `when there is a qualification of type Standard - with subject = Maths there is a qualification of type Higher - with subject = Chemistry then do something` – Francesco Jan 24 '15 at 13:28
  • @Fra, Your's is a valid question. Did you get any answer? If yes kindly post the answer below. I have one more similar problem along with this. Kindly check that here http://stackoverflow.com/q/39898193/1664788 – Vivek Oct 06 '16 at 14:09
  • @Vivek I struggle a bit to recall the problem as long time passed, but it looks that we implemented this way: `[when][][tT]here is an? {qualificationType}={qualificationType}() [when][]- with {field} {operator} {value}={field} {operator} {value}` and this rule works: `There is a GcseQualification - with subject is equal to GcseSubject.MATHS - grade is higher than or equal to GcseGrade.C There is a GcseQualification - with subject is equal to GcseSubject.ENGLISH - grade is higher than or equal to GcseGrade.C` It seems that for us the variable at the end was not necessary. – Francesco Oct 07 '16 at 15:10

1 Answers1

1

You can synthesize the name of a binding variable like any other chunk of text:

[when][]there is a qualification of type {qualification}=
      ${qualification}: {qualification}()

But it's going to be tricky because you'll have to make references to this variable variable variable, too:

[then] print {qualification}=System.out.println( ${qualification} );

instead of the straightforward

[then] print qualification=System.out.println( $qualification );

A lurking danger is that the amount of text that remains as a "landmark" around the macro variables is reduced which may result in multiple matches.

laune
  • 31,114
  • 3
  • 29
  • 42
  • yes this could be one solution but still it's not the ideal :( also I could pass the name of the drools variable as a DSL variable but it will make the DSL more complex and less understandable for a business users. – Francesco Jan 28 '15 at 18:05
  • "understandable for business users" - a myth anyway, unless the DSL is close to trivial, and you are leaving this level, fast. - What do you expect? – laune Jan 28 '15 at 18:09
  • I wouldn't be so negative :) – Francesco Jan 28 '15 at 18:11