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

Lambda-based mapping of an ObjectProvider's object when available or unique [SPR-17170] #21706

Open
spring-projects-issues opened this issue Aug 13, 2018 · 3 comments
Labels
in: core type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 13, 2018

Yanming Zhou opened SPR-17170 and commented

ObjectProvider should accept Function as argument like Consumer #20550

	public default <R> Optional<R> ifAvailable(Function<T, R> dependencyFunction) throws BeansException {
		T dependency = getIfAvailable();
		if (dependency != null) {
			return Optional.ofNullable(dependencyFunction.apply(dependency));
		}
		return Optional.empty();
	}

	public default <R> Optional<R> ifUnique(Function<T, R> dependencyFunction) throws BeansException {
		T dependency = getIfUnique();
		if (dependency != null) {
			return Optional.ofNullable(dependencyFunction.apply(dependency));
		}
		return Optional.empty();
	}

No further details from SPR-17170

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 13, 2018

Juergen Hoeller commented

For the moment, I have the impression that we got enough overloads in ObjectProvider for a start. #16046 added iterable/stream access as well, introducing some additional syntactic complexity there. So I'll rather put this ticket into the backlog and see whether we receive feedback about further demand and specific use cases.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 13, 2018

Yanming Zhou commented

I think mapping is more common used than consuming.

	@Autowired
	private ObjectProvider<OptionalBean> optionalBeanProvider;

	public Optional<String> compute() {
		return optionalBeanProvider.applyIfAvailable(bean -> bean.compute());
	}

can not write using ifAvailable because it raise compile error.

	@Autowired
	private ObjectProvider<OptionalBean> optionalBeanProvider;

	public Optional<String> compute() {
		String result = null; 
		//Local variable result defined in an enclosing scope must be final or effectively final
		optionalBeanProvider.ifAvailable(bean -> result = bean.compute());
		return Optional.ofNullable(result);
	}

It must introduce some ugly variable holder like AutowiredAnnotationBeanPostProcessorTests.ObjectProviderInjectionBean.consumedTestBean

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 13, 2018

Yanming Zhou commented

In functional world, this is necessary trade-off, CompletableFuture has tons of methods.

@spring-projects-issues spring-projects-issues added type: enhancement in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.x Backlog milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core type: enhancement
Projects
None yet
Development

No branches or pull requests

1 participant