<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 9/7/16 4:43 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:9FBAE523-114C-4151-9E6D-F49E21D0C480@osu.edu"
type="cite"><br>
<pre wrap="">I mean constructor arguments. They're inherently a problem when exposing Spring wiring to users, </pre>
</blockquote>
<br>
Well, I personally don't see a huge difference between a property
and a constructor. I use them interchangeably in my own Spring
stuff and honestly haven't really ever thought about them as
distinct. Maybe that's just the programmer in me, and the world
looks different to a non-developer deployer...<br>
<br>
<blockquote cite="mid:9FBAE523-114C-4151-9E6D-F49E21D0C480@osu.edu"
type="cite">
<pre wrap="">and good or bad, that's how this system was built. It was that or custom XML.</pre>
</blockquote>
<br>
That's obviously true.<br>
<br>
<blockquote cite="mid:9FBAE523-114C-4151-9E6D-F49E21D0C480@osu.edu"
type="cite">
<pre wrap="">
</pre>
<br>
<pre wrap="">
I think the point of the Component interfaces was to get to a place where we could use properties safely. </pre>
</blockquote>
<br>
I guess I've always thought of the Component interfaces for things
that were "larger", more important, semi-big ticker. So something
like a Function or Predicate to me doesn't fall into that category
for me.<br>
<br>
Partially, I'm thinking here about lower-level stuff in java-support
and OpenSAML, etc. If most every class as to be initialized(), in
order to avoid having ctors with args, that seems to me to get a bit
unwieldy. <br>
<br>
<blockquote cite="mid:9FBAE523-114C-4151-9E6D-F49E21D0C480@osu.edu"
type="cite">
<pre wrap="">Maybe I'm reading into that, but given the problems with constructors in Spring wiring, that seemed like the point of it to me.</pre>
</blockquote>
<br>
Yeah, I guess we just differ on that. I don't see c:_0="foo" as a
problem, really. Or if that's too unsightly for the non-developer
deployer, then can always just use (ordered) <constructor>
child elements.<br>
<br>
<blockquote cite="mid:9FBAE523-114C-4151-9E6D-F49E21D0C480@osu.edu"
type="cite">
<pre wrap="">
Sometimes it's unavoidable, but I think we could have used the component interfaces more than we did.</pre>
</blockquote>
<br>
Maybe. There could be things that naturally should be components
that aren't.<br>
<br>
<blockquote cite="mid:9FBAE523-114C-4151-9E6D-F49E21D0C480@osu.edu"
type="cite">
<pre wrap="">I inherited a lot of code that didn't use them and also seems to have used constructors and I think that was probably a mistake to keep.</pre>
</blockquote>
<br>
I think the thing about all this that rubs me slightly the wrong way
is that: We say we want to keep (almost all of) our code formally
independent of Spring. But then if we really do (to me) unnatural
things to avoid the use of constructors in favor of properties+init,
just to be more Spring-friendly, then that seems a bit weird.<br>
<br>
</body>
</html>