Skip to content
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

[v3.1] Fix call context when a preference default is a proc #4769

Merged
merged 1 commit into from
Dec 7, 2022

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented Dec 7, 2022

Backport

This will backport the following commits from master to v3.1:

Questions ?

Please refer to the Backport tool documentation

Before v3.1, the proc given as the default value in a preference
had its context bound to the initialized instance.
That allowed, for example, referencing other preferences.

From v3.1., the context is bound to the class.

We are coming back to the behavior by calling the proc with
`instance_exec`

The test changed because initializing `preferences` with
`default_preferences` cause an infinite loop.

This is not a regression as it's the expected behavior on anterior
versions but added some information on the comments.

Change Preference

Context:
- `class A` is declared once in a `before(:all)` so the class WILL NOT be destroyed/recreate for each test
- `@a = A.new` is in a `before(:each)` therefore the variable is initialized before the test start
- The 4 examples from l.285 define the same preference `:secret` but the last one is the only using a default

If the test run first:
- `@a` is instantiated without `preference :secret`
- `@a.preferences` looks like `{:color=>"green"}`
- We define the `preference :secret` with a default
- Calling `@a.get_preference(:secret)` will work because it will look for the default

If the test doesn't run first:
- `@a` is instantiated with a `preference :secret` without `:default`
- `@a.preferences` looks like `{:color=>"green", :secret=>"rJ0s--jPH2d2iyyB9KseLU--HbYfXFtRB36+yj9L3fSDFA=="}
` (`:secret` value is `nil` but encrypted)
- We override `preference :secret` with a default
- `@a.get_preference(:secret)` returns `nil` as it's initialized and does not look for the default

Setting `@a = A.new` after the override works because it'll be initialized with the new default

To fix it we declared the class as anonymous and create them only when needed.

(cherry picked from commit 67bd03d)
@waiting-for-dev waiting-for-dev changed the title [v3.1] Merge pull request #4721 from Roddoric/fix-context-for-proc-in-preferences [v3.1] Fix call context when a preference default is a proc Dec 7, 2022
@waiting-for-dev waiting-for-dev merged commit 237b034 into v3.1 Dec 7, 2022
@waiting-for-dev waiting-for-dev deleted the backport/v3.1/pr-4721 branch December 7, 2022 09:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants