Re: Why C# and Java have got it wrong

From: David Turner (david_at_firepro.co.za)
Date: 02/08/04

  • Next message: Josh Sebastian: "Re: Why C# and Java have got it wrong" 
    Date: 8 Feb 2004 11:52:35 -0800

    Hi Tomasz Zielonka

    I'm going to quote you in reverse order, because I want to agree with
    you before I disagree with you :-).

    Tomasz Zielonka <t.zielonka@zodiac.mimuw.edu.pl> wrote in message news:<slrnc2c131.b3a.t.zielonka@zodiac.mimuw.edu.pl>...
    > Be careful, there are GC languages other than Java. Some of them can
    > even perform this kind of checking at compile time.
    [snip]
    > Perhaps GC doesn't give such a big advantage in Java and C#, but have
    > you used any language which conveniently supports higher order functions
    > and closures?
    [snip]
    > I agree that Java and C# got many things wrong. But please, don't try to
    > extend your bad experience with them to all GCed language
    > implementations.

    You are perfectly correct, and I must apologize: garbage collection is
    a Good Thing (applied in moderation), and I didn't intend to set
    myself up in a position quite so opposed to it. Garbage collection is
    not what I'm attacking; what I *am* attacking is the distraction from
    the real problem that the inclusion of garbage collection in Java has
    ultimately caused.

    So for all the bad things I said or implied about garbage collection,
    I'm sorry. I have no similar criticisms to apply to Lisp, Haskell,
    Scheme, or any number of other gc languages.

    > David Turner wrote:
    > > If an object is to be disposed of, then we must be sure that there are
    > > no references to it. That is the fundamental dangling reference
    > > problem.
    >
    > In C++ you can dispose an object which is still referenced. Even if you
    > use some smart technique like the one you presented, you can still leave
    > a reference to the proxy object living on the stack.

    I'm not 100% sure I know what you mean. Referenced how? Yes, it's
    possible to return a *pointer* to an object in a local scope, and this
    causes many people who are new to C++ endless headaches. Objects
    returned by *reference*, however, are required to have their lifetimes
    extended. As to the proxy object technique I described, as far as I'm
    concerned it's perfectly safe - provided nobody tries to create a
    proxy on the heap.

    By the way, I'm not advocating C++ as a language that is somehow
    "perfect"; I'm simply using it as an example of how things could be
    better in Java and C#. An excellent example of why C++ is not perfect
    has just arisen in the previous paragraph: I would like to be able to
    prevent the use of the "new" keyword in certain contexts, and C++
    doesn't make this possible.

    Regards
    David Turner

  • Next message: Josh Sebastian: "Re: Why C# and Java have got it wrong"

    Relevant Pages

    • Re: The Java no pointer big fat lie!
      ... > reference types, it wouldn't be a good comparison. ... and what you can't - and there is a big difference in Java to C and C++. ... You cannot change it in the language itself, ... Thus I would distinguish pointers from ...
      (comp.lang.java.programmer)
    • Re: call by reference
      ... but if saying "Java has call by reference" makes ... >user of the language shouldn't really need to know how the language is ... but I know that many things about Java made more ... perfect sense. ...
      (comp.lang.java.programmer)
    • Re: Java Generic programming using subclassing
      ... Java nowhere guarantees that the elements of an array ... Now chances are that any Java ... > reference will be visible through the other. ... > eligible for garbage collection, and will in fact be collected before ...
      (comp.lang.java.programmer)
    • Re: pass by reference
      ... talking about Java, that it does when talking about other languages. ... this is also true for "reference" itself. ... Because one "reference" is an object reference, ... This is natural language as I understand it. ...
      (comp.lang.java.programmer)
    • Static typing [was: Benefits of compiler errors]
      ... Java is not statically-typed, but the existence of null is the easiest one to pick one. ... language, which means that every variable and every expression has a type that is known at compile time. ... The null reference can always be cast to any reference type. ... as an authority on type theory, ...
      (comp.lang.java.programmer)