On Mon, 3 May 1999 04:54:48 -0700 (PDT), Troy Wu wrote: >That an import uses a wildcard can also be a strength. One of the >merits of Java lies in its maintainability. Without the ability to >import entire package, packages whose structures are being changed >(generated code is notorious for having this problem) would have large >maintainance issues when names changed. Actually, this is a minor issue. If it is generated code, something needs to know what package to import and change that. Making it import the correct classes directly is trivial. In fact, it is very easy to write an import-converter that makes all * imports be specific (in either way - as in, import all existing classes or import only those that this file actually references) >[...] Also, when you decide to use >another class in your application, you'll have to add the >corresponding import. Sounds like an unnecessary time-sink. It still >doesn't solve the List problem... Well, generally, I require that code documents what it uses anyway. The amount of work to add an import line is minimal and actually is a signal that some extra documentation as to what is being used (and how/where/why) is needed. >Importing each class is somewhat unnecessary, since importing both >java.awt.List and java.util.List doesn't resolve the dependency. >You'd still have to unambiguate between List classes. Well, you are assuming you need both. In which case you would need to fully qualify your name. > To extend your own words, why call it a javax.swing.JPanel > when you can just call it a JPanel? Actually, you got it wrong. The package naming in the front is not the mangling of the name. Why is javax.swing.JPanel not just javax.swing.Panel? After all, the J just makes the name look strange and is not anything specific. The javax.swing.JPanel was named as such in order to try to let you have a unified name space behavior between java.awt and javax.swing which, IMHO, leads you down a path one just does not want to go. > >I agree that one, large namespace is impractical (see C++ =), but >there are times when it's simply more convenient. Design flaws which >deviate from beautiful (IMHO, though it's a little late)can exist--and >should exist, sometimes--for purely pragmatic reasons. > > --troy > > > >---------------------------------------------------------------------- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Michael Sinz -- Director of Research & Development, NextBus Inc. mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com My place on the web ---> http://www.users.fast.net/~michael_sinz ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
