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

Derived data provider #554

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

l0rinc
Copy link
Contributor

@l0rinc l0rinc commented Nov 30, 2015

Where block elements lack consistency in many cases, e.g.:

  • derived parameterizations (b = a + 1) aren't data providers
  • data providers cannot refer to their value
  • data providers cannot refer to previous data providers in a closure
    etc.

To make these possible in the future (but even if not), many affected classes and tests were refactored and provided with comments.

Also, @PendingFeature tests were added to demonstrate the inconsistent behavior.

This commit does not fix these issues, as they proved to be far to complex for a single commit.

Please review the commits separately.


This change is Reviewable

@leonard84
Copy link
Member

Since this PR reformats the SourceCode extensively I would wait for #555 to be implemented.

@l0rinc
Copy link
Contributor Author

l0rinc commented May 21, 2019

Hey @leonard84, would it make sense for me to rebase this PR or should we close it?

@leonard84
Copy link
Member

@paplorinc I'll have to look at this after we merge the spock-2.0 branch, before this it doesn't make sense to invest any work.

@Vampire
Copy link
Member

Vampire commented Mar 22, 2024

@paplorinc many things in this area changed over the last versions with PRs from me.
Would you mind checking with current state whether your changes might still be relevant or not?

Derived Datavariables are still no data providers, but I think they don't need to be anymore.
That you previously could to a certain degree access previous data variables in later data pipes was actually mainly a side-effect of making it possible to access previous columns in data tables.

Accessing previous data variables in later data pipes had many quirks and issues. If I remember correctly, I tried to fix them but in the end came to the conclusion that it is not worth it or not possible. So in 2.0 we made a breaking change and now forbid accessing other data variables due to all the problems and quirks like you could easily prematurely drain iterators, access data providers sooner as expected, behaved differently depending on the concrete code construct used, .... All these points were more confusing than necessary, so we forbid it and now you can only access previous columns in data tables (even across tables in the same where block) or all previous data variables in derived data variables.

So at least now it should behave consistent, even if some accidentally half-available functionality was removed.

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.

3 participants