Why are rules "dynamic" and filters "static" if both are declarative?

[Rudxain]

I'm aware procedural filters exist, but the naming seems misleading to me

[garry-ut99]

Some links with valuable information regarding rules vs filters difference:
(although I can't guarantee that they will answer your question):

• https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide
• https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-precedence
• https://github.com/gorhill/uBlock/wiki/Overview-of-uBlock's-network-filtering-engine%3A-details

[Yuki2718]

I think it's intuitive. Most of static filters are like ||example.com or example.com##.ads which literally filters out network requests or DOM elements. Contrary, dynamic rules are like example.com exampleassets.com * noop which means "If user is on example.com, a request to exampleasets.com is made, and if there is/are blocking rules for the reqeust, cancel the blocking and let the reqeust go through". It's really a rule and not a filter.

[Rudxain]

That's what I thought, until I saw filters like *$font,third-party,domain=~example.com|~example.net, which mean "block requests for 3p fonts, except if the current tab hostname is example.com or example.net". So it seems filters can also be "dynamic" in the sense that they have conditions that depend on tab

[gorhill]

You can set rules with a simple mouse clicks in the user interface, they are virtually zero overhead to create/remove. All filters must be all reloaded in memory when adding/removing.

[Rudxain]

oh, I think I get it now! So "static" means it must be "compiled" ahead-of-time before being used, and "dynamic" means it can effortlessly change at runtime. But then, that implies the naming depends on internal implementation details, which are subject to change

[gorhill]

implementation details, which are subject to change

It's not going to change for static filters -- that would require to completely sacrifice CPU and memory efficiency.