inner class problem~

well like I said, small things like that can be useful (although I still say you just implement Runnable, it’s somewhat rare to be forced to use more than one thread [i.e. client/server apps]).

I’ve seen plenty, plus a rather (humorous?) one where RedHat Linux didn’t support $ in the filename :-/. Multi-platform at its best! :smiley:

I was basing that off my newbie experience years ago. I read a stupid book that said that was the only way to access parent members

To me that’s still a design issue. There are plenty ways to avoid users of your package to initialize a critical class. In my opinion, if you need a “cleaner API” like you said, you could just use private classes and the source wouldn’t be as imposing to newbies (and like I’ve said redundantly, it just seems like better design to me)

That’s just where we disagree and the argument could go forever. Like I said before, it’s the same thing as arguing with people who hate switch/case even though sometimes it seems so useful… yet not considered “standard OO”

My fault for not reading minds. This is a forum… if you’re tired of “explaining” it then you could’ve kept out of the argument all together.

This can be said about any argument if you only rebut 10% of what is said and ignore the other points. However, I agree there is no point arguing. I believe my response above states clear, technical reasons to use them and they are good enough for me.

True, but I saw no argument at that point. I saw an effortless blanket statement and gave it an effortless terse response, assumptions beyond that were your choice.

I didn’t ignore the points, you asked for a justification and I gave you one.

I believe my response above states clear, technical reasons to not use them and they are good enough for me.

[quote]I didn’t ignore the points, you asked for a justification and I gave you one.

I believe my response above states clear, technical reasons to not use them and they are good enough for me.
[/quote]
So far the only clear reason you’ve stated is that you don’t like the fact that it makes a class file with a funny name. That’s pretty ridiculous.

The very usage that you claim is not OO-like is in fact more OO-like than the alternative.


class A {
    class B {
    }
}

keeps things MORE organized by keeping class B contained in class A, the only place where it can be used. Looking through this thread, as I expected, you have been unable to provide any examples of the bug-prone nature of inner classes, and it fact went on to state how useful anonymous inner classes were.

e.g. “small things like that can be useful”

Ahem, inner classes ARE “small things like that”.

No, I also complained it’s bad design (and a needless extra layer of confusion for newbies) and that (to me, imo) completely seperate classes seems more clear and organized. Either way the argument is over for me, kinda hard for people to try to change other people’s opinion :stuck_out_tongue:

So real world example right?

class arithCoder{
class bitCoder{

As you can clearly see this bit coder has zero meaning outside of arith coder. It would be imensely harmfull to implement it as two classes.

best think that could happen would be one more unneccessary method and increased trace for inlining. The worst thing - data corruption.

[quote]No, I also complained it’s bad design
[/quote]
But you haven’t shown how or why.

[quote](and a needless extra layer of confusion for newbies)
[/quote]
Almost everything not absolutely required to implement some basic algorithm is going to be “an extra layer that will confuse newbies”. Is it bad simply because it is an advanced feature? Are newbies forced to use inner-classes?

[quote](to me, imo) completely seperate classes seems more clear and organized.
[/quote]
Other have at least shown evidence that indicates the opposite of what you wrote is true - by showing that the inner class keeps things more organized, and protects against misuse of the inner class.

[quote]Either way the argument is over for me
[/quote]
I’m not trying to argue. I was just trying to get some sort of justification out of you… for making the statement “inner classes is the most pointless and bug-prone feature in Java (and is usually used by newbies to “easily” access the containing class’ variables Undecided). You’d be better off by just using two seperate classes…”

You stated this as a fact, and failed to provide evidence.

I’ve never encountered the newbie use you claim is “usual”. In fact, I’ve found the “usual” use is the very use that you admitted to being “useful”. Nor have I encountered a single inner-class bug. Since you haven’t shown any evidence of such things and are now “giving up,” I can only conclude that your statement is likely to be false.

The fact of it being ‘advanced’ has nothing to do with it. Alot of ‘advanced’ things dont have ‘clearer’ solutions (as inner classes DO have a clearer alternative), I just have a preference to do things a clearer way if at all possible (organization freak? maybe).

You obviously didn’t read all my posts. I did provide examples of why I think its buggy and bad design (and even mentioned RedHat’s ignorance of ‘$’ in a filename, which seems to be fixed in 4.0+)