How to deal with variables

[CurlyMoo]

As @TD-er commented earlier

Apart from this, there is also the question on how to access the parameters that have to be replaced at runtime during rules parsing?
For example, does the rules handler have direct access to UserVar in ESPEasy? Or should there be a call for "give me [taskname#varname] value"?
The same applies for system variables, but those can be encoded using an enum I guess.

The current ESPEasy rules now support something like this [var#%v1%] so that's a 2-step replacement.

[CurlyMoo]

At the moment the variable implementation isn't modular but hardcoded. That means $ and @ are seen as variables. It is well possible to make it modular. There are three functions that check if a specific token is considered a modular value: is_operator, is_function, is_variable. The first two functions are indeed modular. As in, function callback will be called based on a list of functions or a list of operators. The variable can be easily made external so you can define your own variable syntax and attach different functions to different type of variables.

[TD-er]

One simple question here is where are the variables of the rules handler being stored?
In ESPEasy the variables can also be used outside of the rules, in for example a MQTT topic, for a line of text on a display, etc.

[CurlyMoo]

At the moment the variables live inside the rule. However, just as i said, this was a simple matter of getting to a proof-of-concept quick enough to have a actual properly working version. The rule system was primarily developed to be used inside a heatpump community extension board. For that project i currently have the same issue. How to interact with variables outside the rule. But as i was working with it and together with your questions, i think making the variables logic modular is the quick but decent fix.

That means you define three handler:

• It is a variable function for the lexer
• Getting the variable value for the interpreter
• Setting the variable value for the interpret

In that case, it doesn't really matter how you define your variables, as long as the lexer knows how to recognize them you'll be fine.

[TD-er]

So in order to make it less ESPEasy dependent, you may need to provide callback function pointers for get/set variables.
I guess taskvariables are a special kind of variables.

So this begs for the "strategy" design pattern.
In short, we can create a "strategy" struct/functor which allows for a number of standard get/set functions and will allow the interface to the project using your rules.

Typically such a strategy struct uses inheritance where the base class has a number of strictly virtual functions.
So you keep a pointer to the base class and use that for interacting with the outside world.
The strategy object itself is managed by the project using your library.

You can make a basic (dummy) strategy object (using the same inheritance) to hold your own variables.

On my side I can also decide to move the actual data of variables and UserVar inside this strategy object for example.

Very simple example code:

class strategy_base_class {
public:
  virtual ~strategy_base_class(); // This is really important to have a virtual destructor!!!
  virtual double getVar(varIndexType_t variable) = 0;
  virtual void setVar(varIndexType_t variable, double& value) = 0;

};

class my_strategy : strategy_base_class {
public:
  virtual double getVar(varIndexType_t variable);
  virtual void setVar(varIndexType_t variable, double& value)
};

[CurlyMoo]

Indeed, but i for the rules library i'm thinking in C and not C++ (the whole thing is in C) and therefor use more ancient techniques to get to a likewise result.

I would translate your suggestion to a modular token struct:

struct token_sysvar_t {
  int (*isToken)(struct rules_t *obj, int *pos, int size);
  void *(*getValue)(struct rules_t *obj, int step, int *type);
  int (*setValue)(struct rules_t *obj, int step);
} token_sysvar_t;

TLDR: I agree.

[TD-er]

Hmm C-style interface makes it a lot harder to interact.
With a C++ inheritance you could directly interact with objects stored inside the struct.
Not sure how to make an elegant interface to shared data without making either a duplicate interface to this data or changing the interface from ESPEasy point of view into C-style.
Problem with C-style interface is that you have a lot less type checking done at compile time, which is actually a step down from the current code as I have been working hard in the last year(s) to add compile-time type checking to reduce the chance of new bugs to get introduced.

Also not sure if a "double" type is present this way and I guess other projects (e.g. Tasmota) even does use floating point arithmic, let alone using double type as that does add quite a big chunk to the binary size.

[CurlyMoo]

Hmm C-style interface makes it a lot harder to interact.

The discussion C of C++ is not relevant. Making sure the code works and it bug free is. When targeting microcontrollers and IOT, i would just opt for C.

Also not sure if a "double" type is present this way and I guess other projects (e.g. Tasmota) even does use floating point arithmic, let alone using double type as that does add quite a big chunk to the binary size.

I would opt not to include doubles, but to stick with floats and the largest floating point value.

[TD-er]

Well I think it could also be some template type, so you can decide at compile time what's needed.

[CurlyMoo]

Well I think it could also be some template type, so you can decide at compile time what's needed.

Can you elaborate?

[TD-er]

Not sure if you can use the template way as being used in C++.
But using something like this should work:

#ifndef FLOATTYPE
#define FLOATTYPE double
#endif

[CurlyMoo]

Yes, that works.

[CurlyMoo]

I've made the variables logic modular. The interface could be improved though,