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

Create new class that lazily resolves #357

Merged
merged 3 commits into from
Aug 7, 2019
Merged

Conversation

mattcoley
Copy link
Collaborator

@mattcoley mattcoley commented Aug 6, 2019

This could be controversial.
Suppliers are nice to use when a variable that is set in the context that is expensive to calculate may not end up being used. Instead of handling each case individually, we can allow suppliers to be used and automatically call the get() function when we resolve an expression that returns a supplier.
As an example use case, if you are currently building a context map (Map<String, Object>) and want to lazily generate some of the values, you can replace them with suppliers, and due to this PR, the suppliers will auto-resolve.

@mattcoley mattcoley requested a review from boulter August 6, 2019 21:11
@mattcoley
Copy link
Collaborator Author

mattcoley commented Aug 7, 2019

I added an explicit class LazyExpression which takes in a supplier and is auto-resolved instead of auto-resolving all suppliers.

@mattcoley mattcoley changed the title Auto-get suppliers on expression resolution. Create new class that lazily resolves Aug 7, 2019
Copy link
Contributor

@boulter boulter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it.


public class LazyExpression implements Supplier {

private final Supplier supplier;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be Supplier<?>?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or perhaps Supplier<Object>. Maybe that's redundant.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Supplier and Supplier<Object> will compile down to the same code due to how generics work in Java (IIRC) so it won't make a difference.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also only used to return a generic object from the interpreter resolve method so I think this is fine.

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