<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/5/14 11:27 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF187846.864D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
I'm not pushing back on that half being an interface, but I see value in
both of them being interfaces, because a resolver to me should generally
hide the internals of what it's resolving.
</pre>
</blockquote>
<br>
This pretty much relates to the more general discussion we had once
about use of interfaces vs classes. There's no right answer I
suppose.<br>
<br>
I don't personally philosophically have an issue with the -Resolvers
(or in genearl any Resolver impl) being defined as returning a class
vs an interface, if that's what makes sense. Our Resolvers have
often returned an interface, but I don't assume that that is a given
in all cases.<br>
<br>
<blockquote cite="mid:CF187846.864D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I'm imagining a resolver for this sort of information could optimize
things if it was a higher cost operation to resolve certain parts of the
information, so it might do it on demand rather than compute it all up
front and pass back a class.</pre>
</blockquote>
<br>
Theoretically I suppose. I'd like to see a realistic example
though. See below, but: We changed them to simple bean classes
because doing anything else implies having to handle exceptions and
failures in odd places in code that otherwise just wants to call
"Foo getFoo()" and expect to get back either a Foo or null, like a
data holding bean. Doing late binding, resolution, etc complicates
all that.<br>
<br>
<blockquote cite="mid:CF187846.864D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
If for the sake of argument they were both interfaces, then the
interesting question becomes what the actual difference between them is.
Perhaps one interface suffices, and they're just different instances, with
one eventually being the "effective" one.
</pre>
</blockquote>
<br>
Well, perhaps it's gotten lost in all this but: That is exactly
what we originally had: one set of interfaces called
-Configuration. Those were supposed to be "smart" and could or
would do resolution, lookup, etc when they were called. We split
them for the reason above, amongst others. <br>
<br>
Also: a given -Configuration/-Parameter pair right now looks
identical, because I literally did the aforementioned split, and
nothing else, didn't change anything else really at the time. The
goal was just to get nailed down the -Parameters API that runtime
components consume, but the -Configuration(s) may still need some
tweaking. It's not clear that in the end they are going to remain
exactly the way they are. That is part of the TBD work.<br>
<br>
</body>
</html>