Uni.invoke() (or call() or handle())

[gavinking]

After some experience I find I prefer the map()/flatMap() API to onItem().

But it's really annoying that there's no equivalent shortcut way to call UniOnItem.invoke(), since it's an operation I use all the time.

I would like to see invoke() added to Uni, though perhaps it would make more sense to name it handle(), since it's a sort of event handlery thing. Or call() perhaps.

[cescoffier]

This issue came a few times. I, first, need to understand the use case, as most of the time, I've seen these methods used just for log purposes.

We want to add a log operator:

• Uni.log(), Multi.log() - log all the events
• Uni.onItem().log() - log item events
• ...

The log operator can log automatically (using a predefined log statement) or be used with a callback returning the String to be logged.

If requested, the log should be able to clean up the stack trace to be meaningful.

When not used for logging, these methods are often used to implement side-effects. While they cannot be discarded, users must be a bit careful with that.

About the naming, what about onItem(Consumer<T>)? The "traditional" method is named doOnNext which does not fit well with the rest of Mutiny.

[gavinking]

This isn't anything to do with logging. (For logging I would need a matching method that is called on failures.)

It's specifically in order to be able to call side-effects, which are rather hugely important when one is writing data-access code. :-) The most basic operations like persist() and delete() and flush() are all side-effects.

About the naming, what about onItem(Consumer<T>)? The "traditional" method is named doOnNext which does not fit well with the rest of Mutiny.

I want something that looks and feels visually like map() and flatMap(), because it will appear in a chain along with a bunch of map()s and flatMap()s.

[gavinking]

You could call it affect(). Since it's used to cause an effect.

[cescoffier]

I like that name!

@jponge @kenfinnigan WDYT?

[Ladicek]

Is this the same as peek?

[jponge]

affect sounds weird to me, but it's probably due to how I translate that to 🇫🇷 😉

Some random ideas:

• do(Consumer<T> item) (e.g., (...).onNext().do(this::persist).(...)
• perform
• trigger (might be nice)

[gavinking]

do is a keyword in Java.

[gavinking]

And trigger() is almost a bit too exciting and action-packed, perhaps. ;-)

[jponge]

do is a keyword in Java.

Yeah, I thought about it over lunch 🤦

[gavinking]

In fairness, it's probably the least used keyword except for goto and strictfp.

[kenfinnigan]

I kind of like affect().

Some other options could be alter(), perturb(), transform(). Just a few I thought of, though may induce other connotations.

[zeljkot]

peek is already used in Java streams for that purpose. I vote for the peek.

[jponge]

also?

[gavinking]

peek is already used in Java streams for that purpose

I dunno, "peek" sounds kinda like the opposite of what this is. "Peek" sounds like something with no side-effect, whereas we've already established that the whole point of this operation is to do side effects.

[gavinking]

I dunno, "peek" sounds kinda like the opposite of what this is.

I'd be totally happy with calling it "poke", however. 😝

[zeljkot]

Will poke get me infinite threads?

…

On Mon, 1 Jun 2020, 22:17 Gavin King, ***@***.***> wrote: I dunno, "peek" sounds kinda like the opposite of what this is. I'd be totally happy with calling it "poke", however. 😝 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANKF2GHSWMNCFXSMEF7QBLRUQEG3ANCNFSM4NI76VLA> .

[Ladicek]

But peek doesn't have any effect -- on the processing pipeline. It lets you see the value and do something with it, but the pipeline isn't affected. Hence, you could also say that affect is the exact opposite 😁

[gavinking]

Sure, but I'm not writing a code that produces a processing pipeline. I'm writing code that does something interesting to the world. I DGAF what this operation does to the stream, since my program isn't about streams.

[Ladicek]

I'm not writing a code that produces a processing pipeline

Yea, well, you do. If you use the Uni API, you build a pipeline, even though there's ever only 1 item flowing through it.

[gavinking]

Yea, well, you do.

That's the myopic perspective of the designer of a reactive streams library.

It's not my perspective as a user of the API. I'm trying to make an interesting program that does useful things. I actually don't care about reactive streams at all. When I look at my code I want to see information about how my program solves the problem the program is designed to solve. Not information about reactive streams.

[gavinking]

Not information about reactive streams.

And that's why

on().onItem().invoke(sideEffect)

while surely very cool and elegant, arguably, to someone who's very myopically interested in reactive streams, is quite intrusive and annoying in my program which does interesting stuff that end users care about.

[Ladicek]

Actually it's a perspective of someone who hates reactive programming libraries and believes that if we really need to impose them on users, then we shouldn't try to hide what's really going on, because leaking abstraction etc. etc. etc. But I'm ready to agree to disagree.

[gavinking]

Well, I'm trying to find a way to hate it slightly less.

[gavinking]

Alright, so reflecting on @Ladicek point about peek() implying something that has no effect on the stream, I managed to clarify what I dislike about that name, and that suggested a better name.

So why don't I like peek()? Well, "peek" in English means to just sneak a quick glance at the item. Whereas what I'm going to do from this operation is actually use the item to do something very meaningful, perhaps even perform a side-effect on the item itself.

So why not call the operation use()? The name implies to me that I'm going to use the item without affecting or transforming the stream itself. It's a common English word, that's not a Java keyword, and that has just three letters in it!

[gavinking]

Hear me out on this one. This reads really naturally, I think:

return factory.withSession(
	session -> session.find(Book.class, bookId)
		.use(book -> session.remove(book))
		.map(book -> "deleted " + book.title)
);

[zeljkot]

Kotlin has also

return factory.withSession(
	session -> session.find(Book.class, bookId)
		.also(book -> session.remove(book))
		.map(book -> "deleted " + book.title)
);

[zeljkot]

I am sure that every designer of the stream library had the same discussion. We already have a standard Java library. While some names may be less than perfect, they are well known and understood, so why not just stick with that? Easy to use reactive library is something to be excited about; a slightly better name for functionality that I already know under a different name is not.

[gavinking]

I am sure that every designer of the stream library had the same discussion. We already have a standard Java library. While some names may be less than perfect, they are well known and understood, so why not just stick with that?

Ummmmm, because the other APIs are terrible, and terribly confusing?

[cescoffier]

We have tried to use the names from java.util.Stream in MicroProfile reactive streams ops. Feedback has not been good. While "known" it's just confusing and didn't work well (confusing names, hard to find the proper method...).

[cescoffier]

invoke and invokeUni have been added to the Uni class.