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
