Extract "meta" as a type

[sselberg]

Description

All events have a copy/paste duck-type-equal meta property.
Extract this as a specific type.

Motivation

Limits code-duplication and limits event-description complexity.

Exemplification

Benefits

If there needs to be a change in the meta property you'll only need to change it in one place.
Models of eiffel-events could use a type-safe approach without violating the specification.
The (potential) various versions of the meta-object become evident.

Possible Drawbacks

[e-backmark-ericsson]

Actually it was that way some years ago, but the definitions of meta (and links) was decentralised based on this issue: #136. I'm not saying we could not re-evaluate that decision, but please look into that issue and the corresponding PR explaining the reason for decentralising it.

[sselberg]

The reasoning seems to have been that the meta objects could possibly diverge which would cause problems.
This hasn't happened in the four years since, the meta objects are still identical.

In the previous iteration of a shared meta-object the meta-object wasn't versioned, in my version it is. So in the event that the meta object would diverge between events (however unlikely) it would be apparent which version meta-object belonged to which event.

There's an overarching problem with the current Eiffel events specification reluctance to reuse de-facto identical objects since in strongly typed contexts there can only be one Meta object.
The alternative to reusing the object would be to specify that it's not the same object by not reusing "meta" as property.

EiffelSourceChangeCreatedEvent {
   SourceChangeCreatedEventMeta sourceChangeCreatedEventMeta;
}

The problem becomes apparent when you need to rename properties in strongly typed contexts.

The meta seemed like an obvious place to start since it has been identical for all Events for the past 4 years.
From my perspective it would be easier to cross the bridge of diverging meta objects when/if we come to it.

WDYT?

[sselberg]

The bottom line is:

• The commit removes 5000 lines of duplicated code (that hasn't diverged in 4 years) without changing the de-facto specification.
• This duplication is not limited to this specification, it is replicated by every event producer/consumer in every Eiffel-system around the globe.

From my perspective it would be very beneficial if the Eiffel specification went the other way and stated the the "meta" object was not supposed to diverge between events and that event-specific data belongs in the "data" object.
This would be a good step in the direction of making the adoption of Eiffel a lot smoother.
IMM event-specific meta-data is not really meta-data but actual data.

Another drawback of the current situation is that since the properties are named the same ("meta") it implies inheritance (this object has type meta) which is dishonest if they are totally separate objects with no similarity other than that they happen to be formatted the exact same way.

[d-stahl-ericsson]

Great input! There's no obvious right or wrong here, it's a trade-off. The fact that it hasn't changed for four years is a good point - except that it is wrong :) The meta format was last updated in late 2018. But let us not split hairs - it has so far proven to be fairly stable, and may well continue to be fairly stable in the future.

The argument of dishonesty I think misses the point, though. Each event type is independent from every other event type. It constitutes its own namespace, if you will, so there is no naming collision per se.

I'm not sure how moving fields from .meta to .data would solve the problem of boilerplate, though. Supposedly the same fields would need to be represented, and unless we want to extract them (and cause dependencies between versions of events and versions of data elements common to multiple events) we would be moving the boilerplate from one section to the other. But I'm not sure you're suggesting that.

The proposal of creating versioned objects containing shared data fields would work. I'm not sure it's beneficial, though. It's all about whether you want to manage some copy-pasted information or if you want to manage some dependencies. But let's be clear that documentation and implementation are two separate things: writing an event serializer for a specified set of events, I would obviously represent .meta as a shared type.

[sselberg]

"The fact that it hasn't changed for four years is a good point - except that it is wrong"
There's a difference between changing and diverging, I said that the meta object hasn't diverged (implicitly "... between the various events") in 4 years which is true :-)

I don't know that I suggested that we move fields from meta to data. What I was trying to convey was that, if there's a field that would differ between events you could take the standpoint that it belongs in the data object, since the data object is event-specific and meta is not If one were to take my suggested approach and claim that all objects share the same meta object.

"The argument of dishonesty I think misses the point, though. Each event type is independent from every other event type. It constitutes its own namespace, if you will, so there is no naming collision per se."
"But let's be clear that documentation and implementation are two separate things: writing an event serializer for a specified set of events, I would obviously represent .meta as a shared type."

How do you view this as documentation and not specification? Does this not specify how an event of a specific version is constituted?
Implementation that does not follow specification is flawed IMO. If meta object isn't shared in the specification it doesn't make sense to share it in any implementation since it's then not the same object.
But your comment makes it clear that you actually share my view that it is the same object and to pretend anything else (by not specifying it as such) is dishonest IMOHO.

I have set out to implement parts of the Eiffel specification and the lack of reuse struck me as rather awkward. To make matters worse lack of reuse makes the specification a lot harder to read. When getting an understanding for a new event you would only have to bother with reading the data and links properties, currently you have no choice but to read the meta property as well as "it might differ from any other event". Furthermore there are a lot of data properties that should be shared as well such as "gitIdentifier", "personIdent" (differently named, author* etc. but essentially the same object), in fact the only to similarly named data properties that aren't actually the same is (IIRC) outcome which differs from the various .*Completed events but is named the same.

[d-stahl-ericsson]

I think we could get lost in a rather philosophical conversation on what it means to "follow" a specification, and the difference between documentation, specification, protocol... if any. But let's avoid that, those are better saved for musing over a beer at some point.

To stay pragmatic: Yes, there are multiple data elements that are de facto identical, but not defined as shared entities. This was a trade-off decision made, fully recognizing that there are pros and cons:

• The current system introduces copy-pasted boilerplate code. And we all know why that is a bad thing.
• The alternative requires separate versioning and dependency management of shared data elements, which introduces its own complexity and risk of inconsistency.

I can personally see both sides of the matter, and have no strong opinion. Let's see if we can get some more input from the community?