Women in Technology

Hear us Roar



Article:
  10 Reasons We Need Java 3.0
Subject:   more...
Date:   2002-08-05 08:28:33
From:   morbid
Response to: a bunch of amateur ideas...

- .class custom attributes should be accessible programmatically, via ClassLoader API;
- covariant return types should be supported;
- the language should support a proper notion of const-correctness;
Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • Even more...
    2002-08-06 05:31:22  styro [View]

    Most of the points mentioned by Rusty Harold are things that you stumble over when you write books, whereas you point out things that seem to stem from experience in using Java in large scale project (especially the const problem is my prime candidate when debugging).

    I 'd like to add a few ...

    - synchronous destructor/finalizer (in order to use powerful idioms such as allocate/lock-in-ctor, dealloc/unlock in destructor/finalizer). N. B. this does not have anything to do with GC and meory management, there are way more sresources to manage than memory
    - replace String and StringBuffer with String and MutableString (both supporting + operator etc.)
    - operator overleading (I want to define operators for my value types)
    - Fast GUI (move event dispatch to native code)
    • Even more...
      2002-08-12 11:30:44  jacyg [View]

      I agree, though I hadn't thought about it, that Rusty's issues are realy more of an author's, rather than developer's problem. Well said.

      I do take issue, however, with the operator overloading. It's sugar, and it can seem sweet, but it's not good for you. In a large application that uses different libraries, if those different libraries have different operator overloads, keeping track of them can be difficult, and your code can have very well hidden errors (such as could result from using the operators in the wrong order). Now, you may say, "I would do better." but it's really not a good thing for the language. It would not enhance the stability and reliability of the general code-base. And it doesn't add any functionality that doesn't already exist with methods. *And*, if you do implement the funtionality with methods (.add(TypeA, TypeB)), there is a much lesser chance that a programmer could goof and inadvertantly use the wrong method. Operator overloading is just a different method syntax, but it puts the burden of figuring out which method on the compiler rather than the developer, and that's just bound to cause problems.