Forum Stats

  • 3,872,106 Users
  • 2,266,380 Discussions
  • 7,911,050 Comments

Discussions

Generic solution

24

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    dnoyeB: Are you making fun of us?
    I once thought, that you simply didn't care to read
    the specification
    because it's more fun to post to the forum (even
    without any idea what
    you are talking about).
    But you keep missing the point of every single answer,
    so now I guess
    you are simply laughing your a** off about everyone
    who is so dumb to
    answer...
    I dont think so. If you read the posts you wouldn't be saying that.
    If you really mean what you write, here are some
    tips:
    Language Level means Java, compiled code is something
    different
    altogether.
    Its not something different altogether. Its something different, but not altogether. Compiled code has to do with understanding what the Java code is meant to do, and it does have a role.
    You should not (and should never need to)
    care about what
    constructs of virtual machine code the compiler
    generates. (Unless you
    are writing a compiler/decompiler/obfuscator/...)
    If you can't write any JAVA code that causes
    the dynamic casts to
    fail, then at language level there are no casts
    involved.
    I think this is resolved in the posts which you appearantly skipped over.
    Learn that inheritance should always represent an
    "is-a"-relationship.
    This is undescriptive and relative at best. WindowArrayList is-a ArrayList, or is it not? Has all of the properties of an ArrayList but it takes a different type of object. Its upto you which relationship is your focus.
    So you should not really extend any collection class,
    unless your new
    class really is a specialisation of the collection
    class, in which case
    there are no methods to be hidden. This has absolutly
    nothing to do with
    genericity.
    Read the spec. Try to understand it. Read it again.
    ill try...
    C++ templates can be useful, but they always tend to
    become a nightmare.
    They are rarely portable (the C++ spec is much too
    loose about where and
    when to instantiate a template). (Not to mention that
    almost no compiler
    implements all template features, e.g. member function
    templates or
    partial template instantiation.) You cannot separate
    interface and
    definition: For exactly the reason that the template
    isn't exactly a
    class, but rather a blueprint that tells how to
    instantiate a class.
    So a C++ template is much more preprocessor-like as
    the Java
    implementation.

    -
    Are you saying templates in Java will not be compiled into classes or that it will? Some proposals differ on what they desire to do.

    >
    The issue of primitive types is something different
    altogether and as I
    see it, there has been a lot of discussion about it.
    Personally I think there shouldn't have been primitive
    types in Java at
    all. Java implementations could instead have been
    streamlined for fast
    execution of the Integer, Double, ... types. (Like the
    tricks that are
    used in many Smalltalk implementations.)

    The problem as I see it is, that the idea of
    primitives as template
    arguments isn't feasible when you want to have one
    template class
    represented by exactly one implementation. There is no
    super-'class'
    type to all primitive types (like there is Object for
    all classes) that
    can take the place of the template argument in the
    class's byte code and
    can be later dynamically cast to the appropriate
    type.
    I dont agree with the all or none mentality. I agree that primitives are a break from the OO paradigm, but its not a complicated one that adds problems and considering that all primitives behave in a similar fashion and their are only a few, to me its worth it to replicate any needed classes for the speed and memory improvement primitives can offer.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I have already given enough sensible, logical answers to fill a well-written book on generic programming. I give up. I'm going to leave you alone now, as you clearly are not going to understand a single word we say.

    But before I go, i just need to shout one thing:
    Java's generics ARE NOT "Templates"!!!!!!

    Goodbye.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    It is possible to extend the Java generics proposal to include efficient handling of primitives --- there is an old thread in this forum on one way to do this. The main problem is the philosophical one that it doesn't attempt to merge primitives with objects, and thus will incur the wrath of those who believe primitives should be abolished.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I have already given enough sensible, logical answers
    to fill a well-written book on generic programming. I
    give up. I'm going to leave you alone now, as you
    clearly are not going to understand a single word we
    say.

    But before I go, i just need to shout one thing:
    Java's generics ARE NOT "Templates"!!!!!!

    Goodbye.
    Yes, I know. Its just terminology at this point but the prior posts should have led you to believe I understand what Generics are doing and their not Templates. Their not templates because they don't compile from the ground up as I proposed they do. I think templates would be nice, but after our discussion I understand they would not provide more security, and would increase the size of the jar file since the base functionality would be duplicated for each instance. Templates would be faster though since the cast would be gone.

    I was hoping Generics would come up with some fancy way to both use a common base functionality class, but also eliminate the casting. Is their a way to do a cast without a check? Since the compile can vouch for the fact that the cast is static and eternally legal? Of course this would mean the underlying class could not be accessible in any other ways.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You save time, but you also save trouble. Without
    enforcing the correct type of a container, it's
    possible to ship a program with a rare, hidden bug.
    To my mind, that's what typesafety means.
    What im saying is that we already have safety. So this will add a time saver, but maintain the current level of safety.

    Or perhaps you are calling it safe because the fewer keys we type the fewer mistakes we can make? thats a somewhat agreeable point.


    P.S. But hey, don't we get paid to do this? Generics is going to take money away from the programmers! j/k
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You save time, but you also save trouble. Without
    enforcing the correct type of a container, it's
    possible to ship a program with a rare, hidden bug.
    To my mind, that's what typesafety means.
    What im saying is that we already have safety. So
    this will add a time saver, but maintain the current
    level of safety.
    No, generics adds safety because much more type checking is done at compile time. Read the comments by Biil Joy at the bottom of http://www.research.avayalabs.com/user/wadler/pizza/gj/ for more details.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    No, generics adds safety because much more type
    checking is done at compile time. Read the comments by
    Biil Joy at the bottom of
    http://www.research.avayalabs.com/user/wadler/pizza/gj/
    for more details.
    Why? I fail to see why their is MORE type checking at compile time with generics.

    What generics does I can of course do manually. So when you say 'much more', what are you comparing with?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Why? I fail to see why their is MORE type checking at
    compile time with generics.
    Consider this code:
    List li = new ArrayList();
    li.add(new Integer(3));
    String s = (String) li.get(0);
    The third line generates a run-time error because the cast fails.

    Now consider the generic equivalent:
    List<Integer> li = new ArrayList<Integer>();
    li.add(new Integer(3));
    String s = li.get(0);
    The third line now fails to compile.

    It should now be obvious why I say "there is MORE type checking at compile time with generics".

    What generics does I can of course do manually.
    Yes, you can manually add the casts yourself. With generics, you directly tell the compiler your intent and ensures that your code is type-safe. This prevents programmer error.

    So when you say 'much more', what are you comparing with?
    Each cast you manually add can fail at run time. By saying that generic code has much more type checking than non-generic code, I mean exactly that non-generic code has many more casts than generic code. Specifically, many times more casts.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Your only looking at 1/2 the picture.
    Why? I fail to see why their is MORE type checking
    at
    compile time with generics.
    Consider this code:
    List li = new ArrayList();
    li.add(new Integer(3));
    String s = (String) li.get(0);
    The third line generates a run-time error because the
    cast fails.

    Now consider the generic equivalent:
    List<Integer> li = new ArrayList<Integer>();
    li.add(new Integer(3));
    String s = li.get(0);
    The third line now fails to compile.

    It should now be obvious why I say "there is MORE type
    checking at compile time with generics".
    No of course because this example is not equivalent to what Generics does. You must generate your own class that either extends or aggregates List. You have done nothing with List but use it directly, and that is wrong.

    >
    What generics does I can of course do manually.
    Yes, you can manually add the casts yourself. With
    generics, you directly tell the compiler your intent
    and ensures that your code is type-safe. This prevents
    programmer error.
    No, I can manually create the extended or aggregated class myself. I work with a program calle JHotDraw and their is a FigureEnumerator class which returns "Figures" and not Objects. This is what should be done.

    >
    So when you say 'much more', what are you comparing
    with?

    Each cast you manually add can fail at run time. By
    saying that generic code has much more type checking
    than non-generic code, I mean exactly that non-generic
    code has many more casts than generic code.
    Specifically, many times more casts.
    i disagree. Generics will save you typing quite a bit of code, but I still don't see why its adding safety as I have explained above.

    And this is my jist. Its not adding a new ability, just an easier way of getting something done.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    i disagree. Generics will save you typing quite a bit of code, but I
    still don't see why its adding safety as I have explained above.

    Its not adding a new ability, just an easier way of getting something
    done.
    Now I see your point. Yes, if you're a more diglient programmer than I've ever seen and really do go to all the trouble to make all your code type-safe in the manner you describe, generics really doesn't do anything except save you typing.

    But in the real world, people don't do that... they cast the result returned from a method from a more general type to a more specific type. A real-world generics program will have far fewer casts than a real-world non-generics program, and thus is safer in the sense that it's far less likely to get ClassCastExceptions.

    One way or the other, generics makes Java easier to type, or easier to type, or both: http://www.research.avayalabs.com/user/wadler/pizza/gj/ (See the bottom picture and caption).
This discussion has been closed.