Re: what is encapsulation in an interface ?
Lew wrote:
Any argument that justifies by promoting ignorance of the API is thereby
fatally flawed.
Ken Wesson wrote:
I'm not promoting "ignorance of the API"; I'm promoting avoiding the less
well-known corners of it when the alternative isn't significantly long
and convoluted (so, likely to contain bugs, harder to read for intent,
etc.). There is a cost to the maintenance programmer in parsing a short
for loop; there's also a cost to looking up an infrequently-encountered
library function in the API documentation.
In other words, you're promoting ignorance of the collections API.
Pitiful. Go thou and study it!
I'm not saying one must use that method, but I am saying that one must be
aware of it in order to collect pay as a Java programmer.
Also, I work with the API docs open anyway when I write Java code. Don't you?
Would you contend that my eschewing gratuitously imbuing my vernacular
with a vast and varied assortment of obscure, peculiar, and infrequently-
encountered polysyllabic utterances, including multifarious terms of
Greco-Latin etymology, in the interests of committing to this electronic
medium more lucid, concise English prose that will be comprehended with
less difficulty and more alacrity "promoting ignorance of the English
language"? ;)
I contend that that paragraph is completely clear and completely irrelevant.
We are talking about a professional skill for which people claim payment, and
there's a professional standard to apply in that case. Your example has no
such consideration. Were the person in question paid as a grammarian or copy
editor, I would expect them to have at least as little difficulty with that
paragraph as I did.
Let me ask you, did you look up those words to write that paragraph or did you
write that "closed book"?
Occasionally such a word (or API function) makes things *much* shorter
and simpler. This wasn't one of those occasions.
Because of the simplicity of the example. Real-world examples can be (and in
the case of the one I cited, was) more complex.
You seem to think that I am espousing the exclusive use of API calls where
possible to eliminate 'for' loops. That would be a mischaracterization of my
point. I'm saying that /in general/ it's wise to use API calls because they
reduce risk compared to re-inventing their logic. That doesn't mean /always/.
In this profession one must *think*. The dogmatic insistence that the loop
is correct or more clear because it's "obvious" in some restricted use case is
not appropriate.
Lew wrote"
Other than that, the discussion seems to be a matter of style. It is
certainly plausible that the library method would have better
performance than the hand-written 'for' loop, as the java[x].* APIs have
the benefit of close cooperation with the JVM implementation, so an
argument based on performance is a no-go.
Ken Wesson wrote:
I don't agree. It's very unlikely that Collections.frequency is anything
other than an ordinary Java method that gets no special help from the
It's "very unlikely"? Have you checked? Why not?
Where do you get these assertions of probability, anyway? What's your
statistical evidence, hm?
"Likely" or "unlikely" is a boneheaded assessment to make when a few minutes
will determine the answer with certainty. I didn't look it up because it
doesn't matter. In another post, which certainly you must have read, I
pointed out that, worst case, the method wraps the same or equivalent 'for'
loop, from which we can reason that it's unlikely there's much if any
advantage to either idiom compared to the other.
Now to settle it, I will be the bigger man and look it up for you. You're
welcome.
.... ... ... ...
Yep, it's a "tight for loop". Performance difference - negligible and could
go either way.
Next time, instead of making foolish "very unlikely" statistical assertions,
check the facts.
implementation. It is certainly unlikely to be native (and if it was, JNI
call overhead would probably make it SLOWER for all but the largest
collections).
It's so unlikely to be a native call that it isn't one. Probability zero.
You're welcome again.
Lew wrote:
Clarity of "intent" is a specious argument, akin to debating how many
angels can dance on the head of a pin.
Ken Wesson wrote:
If that is your opinion, why have you entered this debate at all?
Why have you?
Lew wrote:
We can and should presume that "any Java novice who has gotten past the
for-loop chapter of his Java 101 textbook" would be familiar with the
collections API and with 'for' loops, so that washes out.
Ken Wesson wrote:
It would seem that there are Java novices and even non-novices that have
long since familiarized themselves with the "for" loop and know much of
the collections API but have never heard of, specifically,
Collections.frequency.
Any self-described Java programmer who isn't aware of at least the possibility
of such a method should switch to a profession whose hardest task is cleaning
off the floor mats at the end of their shift.
Once again you promote ignorance of the API, while uttering mealy-mouthed
denials that that's what you're doing.
Why are you so opposed to a professional being skilled in the fundamental
skills of their profession?
The Collections class alone has fifty methods in it. Are you honestly
expecting everyone to have the whole thing thoroughly memorized? And what
other parts of the API, besides?
Is that what I said? I think not, and if you go back to what I actually said,
I stand by it. If you put up straw-man arguments and knock them down, what
have you won?
Here's what I actually said, and how weird that you can quote it and still
misrepresent it. Did you think no one would notice?
Lew wrote:
(Any self-described "Java programmer" who
does not /at least/ work to keep up to date /at least/ with the
collections API is a saboteur, a bounder, a poseur and a thief.)
Ken Wesson wrote:
Well, this does seem to be a day for unfounded, exaggerated accusations,
doesn't it!
I put the foundation for it in the statement itself. Did you miss it? You
must have. It's not a long sentence; read it again.
And it's not exaggerated. Professionals have a fiduciary responsibility to
keep their skills up to date. Not to do so causes harm, and because the
failure to hone skills is deliberate, that constitutes sabotage of the
affected projects. Such a person is a bounder for being so unethical.
They're a poseur because they represent themselves as professionals without
evincing professional behavior. They're a thief because they collect money
dishonestly.
Thus my claim is both well-founded and not exaggerated.
It's also not an accusation. At least, not unless you found that the shoe
fit, in which case you just accused yourself. Do you /at least/ work to keep
up to date /at least/ with the collections API?
Perhaps you, too, could stand to get a good night's rest before
contributing to this thread again.
Perhaps you, too, could try addressing the points instead of making stupid
rhetorical remarks.
Or maybe you have evidence. How much sleep have I gotten? How much would
constitute "a good night's rest"?
What's the matter, cat got your tongue?
Lew Bloch wrote:
The API approach is less likely to have bugs, generally, than the
hand-written loop approach.
Ken Wesson wrote:
If you can find and demonstrate a bug in the loop I posted, I'll concede
this point, otherwise not. :)
Once again, for the thick of skull, let me repeat that I speak of general
priniciples. Didn't you see the word "generally" in my statement? You did?
What did you think it meant?
And I could care less if you, personally, concede this point. There are a lot
of folks reading this thread who will get to see the logic and truth, and it
is to them I make these statements. You obviously care little for
professional training and standards. I just don't want that attitude to
infect anyone else.
Lew wrote:
In the real-world example of a production system employing professional-
pay-grade developers that I cited earlier, the 'for' loop was complex
and bug-ridden. My colleague's rewrite using 'Set#retainAll()' was bug-
free and easy to confirm that it was so.
Ken Wesson wrote:
Obviously retainAll is more complex, since it must check each item
against a whole list of items to keep and not just one. Though it seems
there's a clear and quick implementation in terms of the from-Collection
Set constructor and the contains method:
Set s2 = new HashSet(c);
for (i = s.iterator(); i.hasNext();)
if (!(s2.contains(i.next()))) i.remove();
Where are your generics?
You have managed to recapitulate pretty much the exact code of the library
method, without the feature of recording whether there actually was a change.
Congratulations, through carefully maintained ignorance of the API you've
managed to re-invent a buggy and less capable version of that particular wheel
that uses more collection objects than the API version already provided.
Plus, if 'c' is not a 'Set' you just destroyed the invariants of that
collection.
You've made my point there. So many flaws in so few lines of code. Just use
the API for God's sake!
(That needs to make a temporary collection as large as the number of
distinct elements in c, so its space complexity is O(c.size()), but its
time complexity is only O(c.size() + s.size()). It also requires the
Exactly. Yet somehow the API call doesn't do that. Hmm.
elements of c and s properly implement hashCode, though that's pretty
In other words, it requires correctly coded elements. Now there's an insight.
You do know that HashSet needs that anyway, right?
typical anyway. (When was the last time you saw retainAll called on a
TreeSet whose elements' hashCode was no good and awful?) The low-space-
complexity version has a nested second loop and O(c.size() * s.size())
time complexity.)
Lew wrote
If 'for' loops were equivalently reliable, how did that happen?
Ken Wesson wrote:
That's a straw man argument. Nobody said for loops were equivalently
reliable; just that one-liner ones are surely not MUCH less reliable (and
easily fixed quickly if a problem DOES arise).
I was speaking in general terms, as you would have known had you not chosen to
ignore every time I said so. Ergo my statement was not a straw-man argument,
and your attempt to mischaracterize it as such in order to avoid the point is
noted.
--
Lew
Ceci n'est pas une pipe.