-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle special modifier "aliases" #92
Comments
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 |
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. |
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. |
Currently we have |
Wouldn't it be too much messages? We could have several boolean flags and one |
We currently have the following fields: (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? |
I think we should make the structure as simple as possible, we can always extend it if we need it later. |
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
For example,
3p
=third-party
is simply an alias, but1p
=~third-party
can be problematic, since the exception marker is handled separately.mp4
=redirect=noopmp4-1s,media
can also be problematic sinceI 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
The text was updated successfully, but these errors were encountered: