what is encapsulation in an interface ?

[Arne Vajhøj]

That depends on the situation, of course. If that less used corner will
save you a lot of time and effort, then I'd have to agree. On the other
hand if we're talking replacing a 59-character, easily understood "for"
loop with a semantically-equivalent, 49-character, roughly-as-easily-
understood API call, then the case becomes equivocal.

And if the API call is a little *less* easily understood, because it's a
"less used corner" and so requires a greater mental effort (or an actual
web search) for the reader to parse, then the balance starts tilting
noticeably in favor of the "for" loop.

You consider moving the cursor over the method and reading
the java docs to be "a greater mental effort".

I am pretty sure that is a lot short of most standards
for developers.

I don't know. The Java 6 API contains everything but the kitchen sink, it
seems to me. Which of course means that *nobody* knows the whole thing
(not even "perfect" Lew) and that all kinds of things are in there for
all kinds of reasons, probably including "it seemed like a good idea at
the time" and the like in some instances. (No claim here that
Collections.frequency is such an instance, though. Or that it is not.)

Nobody has memorized it all.

But most know how to find things very quickly.

It is an essential skill for a Java developer.

That works well when you encounter an unfamiliar API call in somebody
else's code.

Not so well when the query you're thinking of is "what is in the API that
can simplify this code I'm currently writing".

1. First, it has to occur to you that there might be an API that
simplifies the code. If you're writing your own HTTP useragent and
contemplating implementing HTTP itself on top of TCP/IP, it's likely
to occur to you to see if Java's library provides HTTP (as it happens,
it does) and failing that to look for a third party library. If you're
writing a single line of code to count non-nulls in a collection, it's
a lot less likely.

Nay,

0. First, it has to occur to you that your code could even *be*
simplified. And when it's a single line of code as it stands, it
probably won't.

But then also

2. No computer can currently actually execute a query of "what is in the
API that can simplify this code I'm currently writing?". So you'd have
to think of a more specific query. In the case of counting non-nulls,
and given you've already thought that maybe there's an API that will
simplify that, you may well think of seeing if there's an existing
method that counts non-nulls, or non-Xs, or Xs and you can subtract
from c.size().

And

3. So you go looking in HashSet or TreeMap or ArrayList for a method
"count (E object)" and don't find it.

"Collections" is likely to be overlooked -- that's where you go when you
need to synchronize or freeze a collection, isn't it? And we're doing
something else. And if it's not, "Collections.count (E object)" also
doesn't exist. The word "frequency" is unlikely to occur to you if you're
not looking to compare the frequencies of two things, but merely to count
the occurrences (or non-occurrences) of one thing.

Any Java developer should now that Collections class contains various
utility methods for collections. A lot more than synchronize and freeze.
Pretty obvious place to look.

Cue another long, drawn out IDEs-vs.-vi-and-emacs flamewar, in which I
shall refuse to participate on general principle.

Sure but arguing that it is hard to maintain because you don't
want to use a tool that solves the problem does not make the
code hard to maintain - it just make you look inefficient as
maintenance programmer.

Now you're just being vulgar and rude.

Is there nobody in this newsgroup capable of civilized debate?

Well - the argument that because a single piece of code is
correct does in any way contradict that writing one own
implementation is a lot more likely to be buggy than using a widely
used library *is* completely bullshit.

And here comes yet another straw man argument, once again one that would
make a valid point IF I had suggested eschewing API calls in general and
not solely when the alternative code is basically as short and simple as
the API-using code.

I don't see why the argument does not apply to that example as well.

It is not impossible to introduce bugs in short and simple code.

So it is not a strawman - you just don't seem to consider the
problems with your approach.

Arne

 

[Arne Vajhøj]

True, but that doesn't mean encountering an uncommon API call doesn't
require a greater mental effort or a lookup in external documentation of
some sort; it just means that the amount of that greater effort may not
be enormous.

But it still exists, and it can add up over time, too. If we weren't
discussing a loop hardly any longer than the alternative code with the
API call, it probably would not matter; the API call would probably be
preferable.

The time it takes to move the cursor over the method the first time
it is used and the use that knowledge for the future seems to be
rather negligible.

On the other hand, once things get even slightly more complicated (say, 3
+ lines of code) things do tilt rapidly the other way; well-tested
library calls are preferable and code duplication is to be especially
avoided.

The same argument can be applied to 1 line. The relative
cost is smaller, but they still exists.

Arne

 

[Arne Vajhøj]

28, Ken Wesson wrote:
04 PM, Ken Wesson wrote:
[...]
really simplifies and enhances coding power and expressiveness.

I think my for loop is a bit clearer (and probably runs quite a bit
faster) than Tom's code.

Why is it clearer?

You need less detailed knowledge of the API library to know what it
means, for one thing.

If writing your own code instead of using a standard API is a good
thing in general

Nobody claimed that "in general".

True. But there were no indication that it was special case either.

My first "shot" in this petty little "war" was:

I don't know. A tight for loop that clearly and directly expresses the
intent, versus a method call that counts nulls rather than non-nulls,
and a subtraction, and another method call?

Clearly this does not claim to extend beyond the case of choosing between
a short for loop and a short snippet of code that calls a couple of API
methods.

What exactly is your claim?

That any cases of 5 statements (init, for, if, inc, ret) should be
used instead of 1 statement (ret + 2 calls + sub)? Or?

Arne

 

[Arne Vajhøj]

No, it just has to happen fairly frequently.


Perhaps, but it only has to happen once to prove my point above.

Basing advice posted to cljp on something that happens once is
not very good.

That's twice someone's thrown verbal offal in my face in a
disproportionate reaction to any conceivable provocation on my part.


Isn't that the whole point? If you want to separate implementation from
use, wrapping the implementation in a method (or even a whole class) is
the normal way to go about doing it; also if you have multiple places
where you do essentially the same thing, you write one method and call it
from those places instead of duplicating code.


Why would you want to hide it two layers deep though?

Because by using the API solution the maintenance of the
implementation is paid for by SUN/Oracle not the company.

Really, I'm surprised to see so much disagreement arise from one harmless
little for loop!

Arguing that some custom code is better than API calls has a
pretty big potential to disaster of people listen, so you should
not be surprised.

Arne

 

[Jerry Gerrone]

@k22g2000yqh.googlegroups.com>, (e-mail address removed) says...

[rude demand deleted],[insult deleted]

None of the nasty things that Sobol has said or implied about me are
at all true.

I do not take orders from Sobol.

[implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

I do not take orders from you.

 

[Jerry Gerrone]

[snip]

NO FEEDBACK LOOPS!

@k22g2000yqh.googlegroups.com>, (e-mail address removed) says...
No! None of the nasty things that you have said or implied about me
are at all true.
[rude demand deleted],[insult deleted]

None of the nasty things that Sobol has said or implied about me are
at all true.

I do not take orders from Sobol.

He [vicious insult deleted]

No, Lahtinen is the crazy one.

None of the nasty things that Lahtinen has said or implied about me
are at all true.

Sure.

No, Lahtinen is the crazy one.

None of the nasty things that Lahtinen has said or implied about me
are at all true.

But given that he [implied accusation of dishonesty deleted]

No, you're the liar.

None of the nasty things that you have said or implied about me are at
all true.

 

[Mike Schilling]

/were/ unaware.

After all this, I doubt if I'll forget it in a hurry...

-- chris

(And I /still/ can't think of a valid reason for the blasted method to
exist in the first place)

Because of Dan Rather. (What is frequency(), Ken?)