Handle special modifier "aliases"

[scripthunter7]

There are some modifiers that have an equivalent, but it is not just an alias.

After parsing, the modifiers are represented in AST, where a separate property is reserved for

• the name of the modifier,
• the value of the modifier,
• the exception marker (~)

For example, 3p = third-party is simply an alias, but 1p = ~third-party can be problematic, since the exception marker is handled separately.

mp4 = redirect=noopmp4-1s,media can also be problematic since

• represented by two modifiers
• a value must be assigned to redirect

I think it's an alias if only the name is different, but if explicitly different modifiers achieve the same effect, it's a kind of equivalence, not an alias.

These seem more like conversion questions to me. How do we represent these clearly in the compatibility table? Anyone have any good ideas?

Current modifier compatibility table representation: https://github.com/AdguardTeam/AGLint/tree/compatibility-table-4/src/compatibility-tables/modifiers#readme

@ameshkov @Alex-302

[scripthunter7]

I'm thinking something similar to the examples below

adg_any:
  name: 1p
  assignable: false
  negatable: true
  equivalent_to:
    # ~third-party
    - name: third-party
      exception: true

ubo_any:
  name: 1p
  assignable: false
  negatable: true
  aliases:
    - first-party
  equivalent_to:
    # ~third-party
    - name: third-party
      exception: true

adg_any:
  name: mp4
  deprecated: true
  deprecated_message: Use the redirect and media modifiers instead.
  equivalent_to:
    - name: redirect
      value: noopmp4-1s
    - name: media

ubo_any:
  name: mp4
  deprecated: true
  deprecated_message: Use the redirect modifier instead.
  equivalent_to:
    - name: redirect
      value: noopmp4-1s

[ameshkov]

Maybe we should just have a comment field? I don't think we can have a universal "equivalent-to" field that will cover everything.

[scripthunter7]

Maybe we should just have a comment field? I don't think we can have a universal "equivalent-to" field that will cover everything.

I agree with that. It might be useful for the conversion in the future, but not for the compatibility check now.

@Alex-302 I think you should consider transferring these cases from the "alias" column to a "comment" column in the Google Spreadsheet.

[ameshkov]

Regarding the comment field btw.

There are some modifiers that are only supported in nightly versions. We may want to indicate partial support and add additional information to the comment field.

[scripthunter7]

We may want to indicate partial support and add additional information to the comment field.

Currently we have deprecated and deprecation_message fields, following this analogy we could have appreciation and appreciation_message fields or something similar. One is responsible for deprecation, the other for introducing the feature. Or is that too many fields, and just write everything in the comment field? I just got the idea from your comment.

[ameshkov]

Wouldn't it be too much messages? We could have several boolean flags and one comment field for all additional information.

[scripthunter7]

We currently have the following fields:

https://github.com/AdguardTeam/AGLint/tree/master/src/compatibility-tables/modifiers#file-structure

(By the way, many fields are common, so they are not only suitable for modifiers.)

What do you suggest? Should we narrow down this list to make the structure simpler?

[ameshkov]

I think we should make the structure as simple as possible, we can always extend it if we need it later.