# The Emitter Parameter Pattern for Flexible SPI Contracts

DevFeed: [The Emitter Parameter Pattern for Flexible SPI Contracts](<https://devfeed.tech/articles/the-emitter-parameter-pattern-for-flexible-spi-contracts-18811.md>)

Original publisher: [Read original article](<https://www.morling.dev/blog/emitter-parameter-pattern-for-flexible-spis/>)

Published: 2020-05-04T15:30:00Z

Content type: tutorial

Language: en

Sources: [Gunnar Morling](<https://devfeed.tech/sources/gunnar-morling.md>)

Topics: [Frameworks](<https://devfeed.tech/topics/frameworks.md>), [Code](<https://devfeed.tech/topics/code.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [information retrieval](<https://devfeed.tech/topics/information-retrieval.md>), [Machine learning](<https://devfeed.tech/topics/machine-learning.md>)

Tags: [algorithms](<https://devfeed.tech/tags/algorithms.md>), [api](<https://devfeed.tech/tags/api.md>), [code](<https://devfeed.tech/tags/code.md>), [developer](<https://devfeed.tech/tags/developer.md>), [framework](<https://devfeed.tech/tags/framework.md>), [frameworks](<https://devfeed.tech/tags/frameworks.md>), [information-retrieval](<https://devfeed.tech/tags/information-retrieval.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [libraries](<https://devfeed.tech/tags/libraries.md>), [machine-learning](<https://devfeed.tech/tags/machine-learning.md>), [spi](<https://devfeed.tech/tags/spi.md>)

## AI overview

This article explains the emitter parameter pattern as an alternative to return values in service provider interfaces. It discusses how emitter parameters can avoid multiple passes over input, reduce unnecessary allocations, and make SPI contracts easier to evolve when new extracted attributes are added.

## Source excerpt

Table of Contents An Example The Emitter Parameter Pattern For libraries and frameworks it's a common requirement to make specific aspects customizeable via service provider interfaces (SPIs): contracts to be implemented by the application developer, which then are invoked by framework code, adding new or replacing existing functionality. Often times, the method implementations of such an SPI need to return value(s) to the framework. An alternative to return values are "emitter parameters": passed by the framework to the SPI method, they offer an API for receiving value(s) via method calls. Certainly not revolutionary or even a new idea, I find myself using emitter parameters more and more in libraries and frameworks I work on. Hence I'd like to discuss some advantages I perceive about the emitter parameter pattern.