Inner classes are one of several things that were done half-arsed, in order to minimize hits to the JVM. It almost seems like there was a period there when they were afraid to touch the actual JVM so they did obscene stuff in javac instead.
Like I said, lots of the decisions don't appear to have been made on a cost/benefits basis, but rather based on someone's prejudices or perhaps working around an intransigent individual. On Aug 4, 2:09 am, Bob Kerns <r...@acm.org> wrote: > On Aug 3, 10:46 pm, DanH <danhi...@ieee.org> wrote: > > > Just a few bullet points: > > -- I've always thought that C #include processing sucked. Why did > > they never introduce an "#includeonce" directive that would have > > eliminated all the #ifndef stuff to prevent double includes?? > > Even better, go one step further -- call it #import, and put some > constraints on it, like the file has to start and end at top-level, > and no circular imports, and perhaps even that dependencies will be > sorted automatically. > > > -- C macros suck. They obfuscate without really introducing much > > capability. I've worked on languages that had macros that were their > > own language -- you could have real variables in them, loop, do most > > normal programming things. Code was generated via "emit" statements. > > With such a macro language you can do some amazing things, and with > > reasonable use (always a problem, I know) the macros served to clarify > > rather than obfuscate. > > Another model, found in Lisp, Scheme, and Bliss-32, is to construct a > parsed representation of the code you want, and return it. (I'm not > sure if that was in BLISS-16 or not). In Lisp or Scheme, macros are > written in Lisp or Scheme -- in BLISS-32, it's its own language. > > > -- Post-processing of Java bytecodes is expensive and error-prone, and > > again obscures the logic. Not that cost should be a criteria, but > > post-processing is no panacea. > > Yes, no panacea, but it needn't be all that expensive or error-prone. > > And it definitely does NOT need to obscure the logic. In most uses > I've seen or done, it simply implements the logic shown in the source. > It can obscure the flow somewhat, however. But so do inheritance or > delegation. > > I leave it to you to decide whether things like Aspect-J obscure the > logic. > > > -- Yes, one should have to "cost-justify" including a line-number > > pseudo-function in javac. But there are a hundred features of Java > > that don't seem to me to be "cost-justified", and several hundred > > other missing functions that ARE "cost-justified". I never have > > figured out how Sun decided what went into Java and what didn't > > (though in several cases it appears to have depended on what would > > hide the deficiencies in their implementation vs expose them). > > I think I can cost-justify it! It's really easy to do, and it will > take a lot of the wind out of the sails of people demanding Java adopt > the C/C++ preprocessor! :=) More seriously, I think that datastructure > tagging, while not that common, has enough value to justify the low > cost. > > I have my own list of issues with what goes into Java and what > doesn't. #1 would be why we need to use 'final' on variables > referenced in inner classes? Unless, of course, we really want to make > them final. But why should we have to do these stupid tricks to set a > variable from an inner function? It's not like Guy Steele couldn't > teach them how to compile that by now! (His Rabbit and S1 compilers > handled that just fine -- back in the '70's... I spent a lot of time > reading that code...) > > The next few slots would be filled with various generics issues... :=) -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
