Re: [jopr-dev] Event constructor question
i'm guessing that the first variant exists because of data locality;
events are created on the agent side, and then sent up to the server.
so if the agent side doesn't want to keep the entire resource type and,
instead, just use the type name, and i could see why the constructor
looks like that. as for the 2nd constructor variant, i think that was
very likely just copy/paste then add an argument. i took a quick look
at the call hierarchy and the 2nd variant is only used for unit tests.
i agree with that that the type could have been inferred. though,
you'll notice that the last argument is annotated as nullable, whereas
the inferrable arguments are not nullable. but that seems a bit odd,
because if you wanted to pass the arguments explicitly where the source
is not required that, to me, would indicate you should be using the
first variant instead. this seems like it will be a safe fix.
John Mazzitelli wrote:
I have a question about the Event domain object API. It has these two
constructors:
public Event(String type, String sourceLocation, long timestamp,
EventSeverity severity, String detail) public Event(String type,
String sourceLocation, long timestamp, EventSeverity severity, String
detail, *EventSource source*)
I'm questioning that second one. If we accept an EventSource as the
last argument, can't we then infer the values of "type" and
"sourceLocation" and thus shouldn't that constructor be:
public Event(long timestamp, EventSeverity severity, String detail,
EventSource source) {
this.type = source.getEventDefinition().getName;
this.sourceLocation = source.getLocation();
...
}
Otherwise, what prohibits type and sourceLocation parameter values
from (accidentally) being DIFFERENT than that which is found in the
given event source (and if that happens, I assume that would
semantically be wrong).
???
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev