@gselzer Made some progress on the PR chain:
- Merged: #35, #28, #31, #39, #40, #41
- Rebased and cleaned and awaiting my review: #46
- Not yet rebased: #47, #42, #43, #44, #48, #49, #50, #45
I also rebased a couple of old topic branches and pushed them to stale/ prefix to clarify that they are old and may be obsolete now. I didn't finish going through all topic branches on the incubator yet, but the plan is to do that.
You'll end up with
Discoverer<?> e.g. from the ServiceLoader.
I think it would make writing
Discoverer implementations much cleaner
But in practice it would be horrible to use...
But either way you need to do the check, right?
I think it's cleaner not to have the generic. You can ask any discoverer for any type, but some types they just don't care about.
In which situations would having the type parameter make implementing the Discoverer easier?
But I might just have to spend more time cleaning that up...
To summarize, TherapiDiscoverer is an abstract class, whose subclasses need to implement (among less important things):
protected abstract <U> U convert(Discovery<AnnotatedElement> e, Class<U> c);This method is called by
@Override
public <U> List<U> discover(Class<U> c) {
if (!canDiscover(c))
return Collections.emptyList();
List<Discovery<AnnotatedElement>> elements = elementsTaggedWith(tagType());
return convertEach(elements, c);
}
(I've found great use for
Discovery in this one instance, that class will probably be moved into SciJava Discovery Therapi
I'm just going to leave it the way it is
today I saw this and immediately though at when you, Curtis, told me that the community is kind of hating Java. If you got something light to do, you can hear it in background
The remaining question is how we should give
Ops/OpCollections to the StaticDiscoverer in tests
We currently give them classes, but the
Discoverers are supposed to give a list of instances
Starting with SciJava Types, we have this
NilConverter
I think we either:
- Delete the
NilConverter - Introduce SciJava Converter2 to the incubator
Any opinions?
(Additionally,
Types depends on org.scijava.util.MiscUtils.compare, but I'm just going to figure out how to get the same functionality without that dependency)
Currently it only has
Validated, ValidityProblem, and ValidityException in the org.scijava.common3.validity package
Debating adding
Priority to that as well
Any opinions on Priority?
5 replies
@gselzer I'm curious if you ever read the dev.java/learn tutorials, e.g. decoupling modules with services. I'm going to check them out this week.
5 replies
Although it uses
POM and Manifest (and by extension Versioned), which live in the package org.scijava.util...
5 replies
I cannot decide where it should live, personally. We can always recover it if we decide that we need it at a later date
In case anyone else finds this interesting, IntelliJ was giving me warnings for many of my
StringBuilder.append() calls that included some String variable. What might be better known is that String concatenation with variables uses new StringBuilder().append(s1)...append(sN).toString()uner the hood. What I learned was that chaining calls are heavily optimized over sequential calls.