To be more specific, then, I'm implementing a new background task for the ERJasperReports.framework which I'm calling ERJRDataSourceReportTask. It's analogous to the existing ERJRFetchSpecificationReportTask, but takes an ERJRFoundationDataSource instead
of a fetch specification. For our purposes here, we probably only need to know that the latter just takes an NSArray<? extends NSKeyValueCodingAdditions>. So here's part of the new class:
publicclass ERJRDataSourceReportTask
implements Callable<File>, IERXPercentComplete {
public ERJRDataSourceReportTask(ERJRFoundationDataSource dataSource,
String reportName) {
// ...
}
Ideally I'd like to keep it general like this (that is, accepting ERJRFoundationDataSource in the constructor), but what happens in the specific case where the NSArray<? extends NSKeyValueCodingAdditions> backing that is actually an NSArray<EOEnterpriseObject>?
Should I look for that specific case (in the task's constructor above), then pull out all the EOGlobalIDs, and then re-create all the EOs via those EOGlobalIDs right there on the spot? I mean, presumably this is equivalent to having the caller supply an
array of EOGlobalIDs (because the _constructor_ is running in the same original thread), but what I've just described sounds ridiculous, doesn't it?
What I would like to avoid is a special-case constructor accepting NSArray<EOGlobalID>, but I could do that if I had to. Any thoughts?