Clojurians Log v2

Well, if the type of field value remained the same, and the name were not used internally in the code base, there wouldn't even really be a need to change the name of the Java object's field that represented it, as long as you were willing to live with the name difference between external data and internal representation.

@andy.fingerhut in classic Java or in DOP Java?

Changing names == breaking things. (That’s how you end with misspelt http headers.) Coping with a new field is more interesting: new protocol version, or db schema update. What do you do of this new field your app doesn’t care about (say you are filtering/routing events: you need to lug the field around you don’t need to model it)

fields renaming is close to being a strawman

In classic java, does the code that implements filtering/routing events logic need to import class definitions for all types of events? I guess there are “design patterns” that make it possible to have different type of events with a common minimal set of fields to be processed by “generic” code.

It’s not about header vs payload

It’s about payload evolution

you dispatch purchase events based on amount

new version of the message comes in because of some new VAT regulation

you don’t care about the extra fields

but you need to pass them down

How do they manage it in classic Java? They add the new fields to the Event class?

Today I learned what is a strawman https://en.wikipedia.org/wiki/Straw_man

Either they go with a stratified approach (discrete typed getters + generic get — possibly generic gets, one for each type: getString, getLong etc.)

which allows to not break on payload extension (because backed by a map)

or they map each message piece as a class field and you get brittle code.

What are discrete typed getters? Is it something like m.getAsString("price") ?

By discrete getters I mean getName getPrice and the like

GetAsString is a typed generic getter

Are the terms “discrete getter” and “typed generic getter” well known terms?

Nope