what is encapsulation in an interface ?

[Jerry Gerrone]

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

[implied insult deleted]. I should have realized that mentioning that
particular [insult deleted] would probably summon him up.

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

[calls me a liar]

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

I typically find that if Lew and Arne are flaming someone, there is a
reason.

[implied insult deleted] agree with Twisted here -- there
is nothing I have written here that is any call for Lew to accuse me of
being a thief or for Arne to be slinging four-letter epithets at me, yet
those things have both recently happened.

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

I can't comment about your relationship with the other regulars, Jerry

Neither can I, if only because [implied insult deleted].

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

 

[Jerry Gerrone]

Nobody suggested catering to developers that don't know how to find
stuff. The claim I made that you have somehow [suspected implied insult
deleted]

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

Wow, [insult deleted]!

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

Note: "twisted" in this case is the past participle form of the verb "to
twist", not a reference to a Usenet poster.

I'm fairly sure the capitalization was deliberate, and Ken meant to
imply that Arne's bad behavior reminded him of me, as a way of
insulting Arne. Obviously, that implies an equivalent insult against
me.

In reality, of course, none of the nasty things that Wesson has said
or implied about me are at all true.

 

[Jerry Gerrone]

That's classic cljp regular behavior, alright. I see that things
haven't changed in the years since my last post here. Let me guess,
newbies still get hazed mercilessly, too? And Lew, Arne, and Peter
Duniho are the main triad of evil, with occasional flamey
contributions by the rest of the usual suspects from way back when?
[calls me a liar]

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

Um, [calls me a liar].

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

Go back and read what I said.

Why would I want to read your insult a second time? It was nasty
enough having to do that *once*.

I was sharing my experiences regarding Arne and Lew.

Not just that; you were claiming that mine couldn't possibly have
happened the way I'd claimed. In other words, implying that I'd lied.

I had not lied.

[implied insults deleted]

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

Wait. No, I don't. [implied insult deleted]

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

 

[Jerry Gerrone]

Nice intentional misspelling of my name.

I'm glad you liked it.

Um, [calls me a liar].

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

[insult deleted]

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

 

[Jukka Lahtinen]

Go away, asshole.

He looks like a paranoid who deserves to be plonked.

 

[Mike Schilling]

On Jan 5, 12:02 am, Steve Cobol <[email protected]> wrote:

Nice intentional misspelling of my name.

Um, [calls me a liar].

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

Go away, asshole.

The only way to accomplish that is to stop replying to him. Otherwise,
we're on the path to another many-thousand-post flamefest (and no, I am not
exaggerating.)

 

[Joshua Cranmer]

The only way to accomplish that is to stop replying to him. Otherwise,
we're on the path to another many-thousand-post flamefest (and no, I am
not exaggerating.)

Which thread was the first big one again? It's been so long I've
forgotten, although I do remember one of my threads ended up being the
start of one of the wars.

 

[Jerry Gerrone]

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

[insult and rude demand deleted].

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

He looks like a [vicious insult deleted].

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

 

[Jerry Gerrone]

Glad you liked it.

Um, [calls me a liar].
No! None of the nasty things that you have said or implied about me
are at all true.

[insult and rude demand deleted].

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

[implied insults towards me, and threat towards both of us, deleted]

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

I don't respond well to threats.

 

[Jerry Gerrone]

[implied insult deleted].

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

Which thread was the first big one again? It's been so long I've
forgotten, although I do remember one of my threads ended up being the
start of one of the wars.

There was a big thread that rambled through many topics, then settled
eventually to myself and Bent Dalager arguing against Oliver Wong's
support of draconian copyright law.

This was eclipsed by a later blowup triggered by blmblm. That one was
some months later and was on the topic of modern software vs. command
line tools, vi, and emacs.

The one that developed in a thread you started wasn't that one. It
might have been the copyright one, though. I don't recall.

 

[Mike Schilling]

Oh dear God, what have I unleashed?

Sorry, guys. I had *no* idea merely mentioning him could start all of
that up again in earnest. I thought at worst he'd show up, make a post or
two to say none of the nasty things I'd said about him were true, and
then leave.

See why we were warning you against loops?

 

[Jerry Gerrone]

Which thread was the first big one again? It's been so long I've
forgotten, although I do remember one of my threads ended up being the
start of one of the wars.

[serious implied insults deleted]

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

 

[Jerry Gerrone]

[serious implied insult deleted]

NO FEEDBACK LOOPS!

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

 

[Arne Vajhøj]

No, it's not a disaster. Encountering its use in code, I'd look at the
context and the arguments and figure out what it does, probably checking
the API docs real quick to confirm that the writer meant "count".

However - and not with the Collections class specifically - bad naming
of this type might cause me to overlook a method if I were scanning
names in the top part of a class Javadoc. "frequency" in Collections I'd
probably catch (assuming that I was completely unfamiliar with that
class) as being really a "count" method. But I suspect I probably _have_
missed other API methods in the past simply because the authors couldn't
be arsed to give them a good name.

Arne points out that statisticians do use the term frequency for counts,
both absolute and relative. Point conceded. But how many developers are
familiar with statistics?

Some but definitely a minority.

And just to make it clear - I completely agree that it is
very important to name Java API methods properly meaning
that the name clearly indicates functionality for as wide
an audience as possible.

I just don't think I would avoid a method just because
of the naming.

Arne

 

[Arne Vajhøj]

On 11-01-02 04:57 AM, Ken Wesson wrote:
On Sat, 01 Jan 2011 10:53:15 -0500, Lew wrote:
[ SNIP ]

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.

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
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).
[ SNIP ]

I'm basically neutral in this discussion so far, but I have to agree
with you (Ken) insofar as I disagree with the blanket statement that
"java[x].* APIs have the benefit of close cooperation with the JVM
implementation".

"Close cooperation"? And hence implicitly better performance? I don't
get that at all. Moving on from Ken's observations, and looking at
_human_ cooperation, I have strong doubts that just because a developer
working on the Collections API is more strongly related, officially, to
a JVM developer, than a third-party programmer, that we're typically and
commonly getting tighter, faster, more reliable code because of it.

I think the benefits to be had are those that you'd expect from any
library that gets used enough. Lots of eyeballs, lots of testing.
Period. There's nothing intrinsically special about the java[x] APIs -
Sun (and now Oracle) didn't/doesn't employ all Josh Bloch's to write
that stuff. In no few cases the java[x] API designs are mediocre, and
always have been - it's not all superstars writing this code.

That is correct.

But there should be a decent chance that the worst catastrophes
get fixed more quickly in a commonly used library than in a projects
reimplementing Java API functionality code.

Yes, which was my point in my first few sentences in my last quoted
paragraph above. Lots of traffic so hopefully quick action on defects or
performance or useability.

But that argument works better for non-trivial methods.
Collections.frequency _is_ trivial.

Even though I am still waiting for String replace to get
enhanced.

What enhancement is that?

Current implementation (at least the last 1.6 I checked) uses
regex with LITERAL.

Arne

 

[Arne Vajhøj]

No more than a writer who doesn't use long and uncommon words just
because they're there, but only when they improve clarity or precision,
is promoting ignorance of the dictionary.

That writer is not suggesting anybody to ignore the API.

He just gives those that want to be ignorant an excuse.

How fortunate it is for us Java programmers that you aren't the world
arbiter of who gets to collect pay as a Java programmer, then, because
the Java APIs contain an estimated 50,000 or more methods in total!

As of 1.6 is is almost 100000.

Of course, but it still costs at least a little bit of time to switch to
the browser, switch browser tabs, mentally switch gears from "reading/
writing code" to "reading docu", etc.

May I suggest a better IDE. One with support for Java docs.

Sometimes the savings from using an API method outweigh those costs. If
the function is extremely well known; or the alternative is a long and
complex block of code; then the API method wins.

On the other hand, if it saves all of eight characters or so and doesn't
really simplify anything, and the function is not as well known, it's
clearly a more equivocal case.

Frankly I'm surprised so many people here have such strong opinions on
the matter, on both sides of this issue, when it comes to cases like that
"for" loop where the non-API-using code is very short and the two options
are probably close to equivalent in total lifecycle costs.

It comes with experience about how bad those homegrown
solutions can be for a project.

Very simple statistical reasoning: they won't have done any fancy (native
or whatever) implementation tricks in every one of the library's tens of
thousands of methods; only in cases where it would produce big
performance benefits for a lot of users, or where the API needs to
interface to lower levels of the system (low-level I/O, AWT toolkits, VM/
system-interop stuff in System and java.lang.ref, and so forth).

Collections.frequency is in neither category. There's no clear reason to
implement it as anything but "int i = 0; for (Object o: c) if (o ==
target || (o != null&& o.equals(target))) i++; return i;" or Java code
to that effect.

No reason not to is not a very good criteria for deciding to
implement ones own version.

A second line of reasoning that leads to the same (probabilistic)
conclusion is that the JNI overhead from implementing something like that
as a native method would be prohibitive for smallish collections, so a
native-method implementation would not be suited to the general case.

I completely agree with that.

Arne

 

[Arne Vajhøj]

I will not stoop further than that, however; if I feel the urge to, I
shall instead killfile you and possibly Arne and save us all a lot of
grief.

And I am increasingly feeling the urge to.

Do you need help to how to do it??

Arne

 

[Arne Vajhøj]

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

Go away, asshole.

Unfortunately wishes does not always come true.

Arne

 

[Arne Vajhøj]

He looks like a paranoid who deserves to be plonked.

Sure.

But given that he creates new gmail accounts faster
than we can count, then ...

Arne

 

[Arne Vajhøj]

Everyone on staff surely already knows about for loops.

That would be a common assumption.

But if restrict it to developers that does not know how about
Collections class and how to see methods and docs inside their
IDE, then I have my doubt.

Yes. So? First of all, "how to quickly lookup things in the Java API
docs" does not address "how to know whether something relevant exists in
the API docs even if there's no reason it would even occur to you to
think it might", such as when coding countNonNulls; nor does it magically
make the maintenance programmer able to *instantly* lookup things without
*any* reduction in speed when they hit an unfamiliar API call in code
they're working on in place of equally-short, basic Java they do
understand at a glance.

If the idea that such a method could exist did not occur to them,
then that is fine.

If they after being told that it exists still not want to use
it, then they seems against learning new things and does
not have much of a future in programming.

The maintenance programmer just move the cursor over the method
and read the Java docs.

I didn't say that. That's another of your growing collection of straw men.

Oh, no, it's not. It's the same tired old straw man appearing over and
over again. Can't you even think up a new straw man now and again? Are
you that uncreative?

What I wrote is, of course, an argument that there is a balance between
writing the functionality yourself and calling the API, and that that
balance, while usually tipped way over to favoring calling the API, can
level out or even tilt the other way when the API in question is
relatively obscure and the alternative is very short and clear (say, one
line of easily-understood, normal Java).

And that is against all ideas in reusable libraries, so it was
not a strawman argument.

If we were arguing in general, I'd agree with you. But there can be
specific exceptions in cases where the API call does not make things
significantly shorter or clearer.

But that just makes it a little bit bad instead of very bad.

another of your straw men. Finally! Now you have two. Maybe they can go
start a family of cute little straw kids now.

Nobody suggested catering to developers that don't know how to find
stuff. The claim I made that you have somehow Twisted into that nonsense
was merely that it takes greater than zero seconds to look stuff up in
the API docs; a claim that surely no sane person would dispute.

If you divide the time it takes to read the collections API's
with how often you will need to use that stuff, then it will
be very close to zero.

This is the reusability aspect.

One of the benefits of libraries over one off code.

Arne