Page 3 of 5 FirstFirst 12345 LastLast
Results 41 to 60 of 82
Like Tree9Likes

Thread: Generics & 'Type Erasure': disingenuous documentation?

  1. #41
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    And?
    Is that an actual occurrence you have encountered?
    If I give a real live example, I may as well sign my name at the bottom. The example I have given is made up of real live scenarios which I have encountered.

    Quote Originally Posted by Tolls View Post
    As I said, I have worked in Java for over a decade and this is not something I have ever encountered post-1.5.
    I suppose it depends on what type of projects you have worked on.

    Quote Originally Posted by Tolls View Post
    No one is keeping anything hidden here...it is simply not happening the way you seem to think it is.
    Actually, it is fairly wide spread. Selling the product is often part of documentation. For example, everyone has heard of "bugs" being classified as "features". And how many products have you come across with claims of compliance with a standard that have to be taken with a large grain of salt. MS Access JDBC supports the serializable transaction level, yeah right.

    Problem is, it makes the documentation woolly to say the least.

    Quote Originally Posted by Tolls View Post
    Even pre-1.5 the interfaces were well documented (by necessity, sadly), and any use of an Object[] like that would have been questioned in any case.
    But not in bespoke software where legacy data structures (or should we call them unstructures) are being modelled. Another area I have seen such usage is messaging. In either case the structure of the data is held in meta-data headers within the structure itself. This is because the structure is relatively dynamic.

    Quote Originally Posted by Tolls View Post
    You talked earlier about the cost of this, but I suspect you don't realise what the cost of a reworking of (quite possibly) the JRE itself, or the dismantling of the Collections framework to accommodate this change, would entail. Regression testing for a simple JRE upgrade is fairly expensive as it is, but doing it for something that will likely break legacy code will simply result in companies not bothering to stump up the dosh.
    I have worked with products from inception to sun-setting, and I am very aware of the costs and stability issues. Cost may make a particular implementation reasonable. It does not make it logically valid, and it should not be argued as such.

    I think the elements are already in the product. The compiler knows when a line mixes raw and parametrized types, and the runtime already stamps arrays with their type.

    What I suspect is the case, is that stamping a parametrized type with its type is that much more difficult because the structures involved may be very complex.

  2. #42
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,863
    Rep Power
    19

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    If I give a real live example, I may as well sign my name at the bottom. The example I have given is made up of real live scenarios which I have encountered.
    OK, but then we have a problem as I have nothing to comment on.
    Academic ideas with no solid foundation really don't make for much of an argument.
    There's nothing I can comment on.


    Quote Originally Posted by 2by4 View Post
    I suppose it depends on what type of projects you have worked on.
    Finance, media, travel, public sector, marketing...most with legacy aspects underneath.

    Quote Originally Posted by 2by4 View Post
    Actually, it is fairly wide spread. Selling the product is often part of documentation. For example, everyone has heard of "bugs" being classified as "features". And how many products have you come across with claims of compliance with a standard that have to be taken with a large grain of salt. MS Access JDBC supports the serializable transaction level, yeah right.
    Access really isn't a good example...anyone that uses that in anything approaching a serious environment deserves all they get, frankly.
    Especially in this day and age.

    Quote Originally Posted by 2by4 View Post
    Problem is, it makes the documentation woolly to say the least.
    The interface with a system should be properly documented...no two ways about it.

    Quote Originally Posted by 2by4 View Post
    But not in bespoke software where legacy data structures (or should we call them unstructures) are being modelled. Another area I have seen such usage is messaging. In either case the structure of the data is held in meta-data headers within the structure itself. This is because the structure is relatively dynamic.
    Then wrap them.
    You don't interact with a legacy product directly.
    Never.
    When you are developing a new system (or upgrading an old one) those parts that are not changing are wrapped to ensure the legacy system receives what it expects to receive, and the new stuff is forced to pass the correct structures over. This also allows you to change the wrapped code as time and budgets allow.

    Possibly that's why I've enver encountered this problem.

    Quote Originally Posted by 2by4 View Post
    I have worked with products from inception to sun-setting, and I am very aware of the costs and stability issues. Cost may make a particular implementation reasonable. It does not make it logically valid, and it should not be argued as such.

    I think the elements are already in the product. The compiler knows when a line mixes raw and parametrized types, and the runtime already stamps arrays with their type.

    What I suspect is the case, is that stamping a parametrized type with its type is that much more difficult because the structures involved may be very complex.
    Also it needs to be backwards compatible, and the Collections framework being one of the fundamental parts of the JDK cannot simply be restructured in this way without risking that compatibility. If it were easy it would have appeared in 5, or 6, or 7...and it's not even ear-marked for 8.

  3. #43
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    OK, but then we have a problem as I have nothing to comment on.
    Academic ideas with no solid foundation really don't make for much of an argument.
    There's nothing I can comment on.
    Calling it academic because I don't post live code and identify myself is hardly an argument.

    Finance, media, travel, public sector, marketing...most with legacy aspects underneath.
    That's a lot of bouncing around in 10 years (jk).

    Access really isn't a good example...anyone that uses that in anything approaching a serious environment deserves all they get, frankly.
    Especially in this day and age.
    You like to sidestep points, don't you. The point here is about documentation being less that transparent, not whether MS Access is an appropriate solution. Microsoft are usually good at documentation.

    The interface with a system should be properly documented...no two ways about it.
    And that goes for generics on the Java Platform.

    Then wrap them.
    You don't interact with a legacy product directly.
    Never.
    When you are developing a new system (or upgrading an old one) those parts that are not changing are wrapped to ensure the legacy system receives what it expects to receive, and the new stuff is forced to pass the correct structures over. This also allows you to change the wrapped code as time and budgets allow.
    The whole point is that the data structure is varying and data types specified by meta data, so at some point you will need Object[]. Wrapping won't help, there.

    Quote Originally Posted by Tolls View Post
    Possibly that's why I've enver encountered this problem.
    Possibly not.

    Also it needs to be backwards compatible, and the Collections framework being one of the fundamental parts of the JDK cannot simply be restructured in this way without risking that compatibility. If it were easy it would have appeared in 5, or 6, or 7...and it's not even ear-marked for 8.
    It doesn't have to be done in one hit. In 7, they have already included the warnings from the call site also on the offending method. Further compile time enhancements can be made by moving the warnings to those sites that are being defensively called "valid". So long as the runtime check is not there, those sites are not valid. Check out this earlier documentation I found, which was more forthcoming...

    The Fine Print

    Arrays

    The component type of an array object may not be a type variable or a parameterized type, unless it is an (unbounded) wildcard type.You can declare array types whose element type is a type variable or a parameterized type, but not array objects.

    This is annoying, to be sure. This restriction is necessary to avoid situations like:

    // Not really allowed.
    List<String>[] lsa = new List<String>[10];
    Object o = lsa;
    Object[] oa = (Object[]) o;
    List<Integer> li = new ArrayList<Integer>();
    li.add(new Integer(3));
    // Unsound, but passes run time
    // store check

    oa[1] = li;

    // Run-time error: ClassCastException.
    String s = lsa[1].get(0);
    Notice that

    1. They candidly declare the section as "The fine print", (read small print).

    2. An assignment to Object, which you have said is ALWAYS valid, is described here as "unsound".

    The reasons given are more direct and clearer, but this edition was toned down. That is the main thrust of this thread. Good documentation should not obscure facts.
    Last edited by 2by4; 12-20-2011 at 10:18 AM.

  4. #44
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,863
    Rep Power
    19

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    Calling it academic because I don't post live code and identify myself is hardly an argument.
    But without actual real life code it is by nature going to be academic.
    And academic will not drive a change of this nature without evidence this is being encountered as a major problem.
    I very much doubt change requests are being hidden...

    Quote Originally Posted by 2by4 View Post
    That's a lot of bouncing around in 10 years (jk).
    7 years of contracting will do that for you.
    Media and defence before that.

    Quote Originally Posted by 2by4 View Post
    You like to sidestep points, don't you. The point here is about documentation being less that transparent, not whether MS Access is an appropriate solution. Microsoft are usually good at documentation.
    Except where Java/Access is concerned. Otherwise they might have deigned to provide a driver for it, instead of relying on the notoriously flaky bridge.
    So not a great example.

    Quote Originally Posted by 2by4 View Post
    And that goes for generics on the Java Platform.
    It is documented. If you have code that actually does some of the stuff mentioned in this thread then there is something wrong. And it's not with Java.


    Quote Originally Posted by 2by4 View Post
    The whole point is that the data structure is varying and data types specified by meta data, so at some point you will need Object[]. Wrapping won't help, there.
    Yes it will.
    Short of Hibernate-esque frameworks (which should also be wrapped based on your business logic) there is no reason your main business code requires the use of Object[]. For example, I am currently doing stored procedure work. By the very nature of Structs and their attribute arrays we do deal with Object[]...similar to hibernate in that respect. Those arrays never escape the DAO, hence they have no chance to pollute the main system. If you have a legacy system that uses Object[] inside them then there should be a wrapper/interface that protects the new code from this legacy code, and similarly prevents these things from getting out.

    Quote Originally Posted by 2by4 View Post
    Possibly not.
    See above. I write code to avoid these situations. I have worked with legacy systems often enough to know the pitfalls of earlier designs, and the new stuff screens it off. If you see Object[], or raw collections then you stick something in front of it to ensure the correct structure is passed down from the area you are working on.

    Quote Originally Posted by 2by4 View Post
    It doesn't have to be done in one hit. In 7, they have already included the warnings from the call site also on the offending method. Further compile time enhancements can be made by moving the warnings to those sites that are being defensively called "valid". So long as the runtime check is not there, those sites are not valid. Check out this earlier documentation I found, which was more forthcoming...

    The Fine Print



    Notice that

    1. They candidly declare the section as "The fine print", (read small print).

    2. An assignment to Object, which you have said is ALWAYS valid, is described here as "unsound".

    The reasons given are more direct and clearer, but this edition was toned down. That is the main thrust of this thread. Good documentation should not obscure facts.
    But it is valid. It is also unsound.
    It is quite possible for code to be both.
    KevinWorkman and JosAH like this.

  5. #45
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    You are repeating your viewpoint without adding to it. So I will skip that. Suffice to say that I too have similar contracting experience, mainly in finance.

    MS Access makes the same claim for its ODBC driver (in fact that is where I first came across it). So your Java "exception" does not stand.

    I was also appalled at the documentation for the psql driver, which claimed to be compliant, but tried to explain away an omission of a feature which other compliant drivers had implemented.

    Yes it will.
    Short of Hibernate-esque frameworks (which should also be wrapped based on your business logic) there is no reason your main business code requires the use of Object[]. For example, I am currently doing stored procedure work. By the very nature of Structs and their attribute arrays we do deal with Object[]...similar to hibernate in that respect. Those arrays never escape the DAO, hence they have no chance to pollute the main system. If you have a legacy system that uses Object[] inside them then there should be a wrapper/interface that protects the new code from this legacy code, and similarly prevents these things from getting out.
    Not a good argument. The developer should not have to know if legacy code "uses Object[] inside of it".

    See above. I write code to avoid these situations. I have worked with legacy systems often enough to know the pitfalls of earlier designs, and the new stuff screens it off. If you see Object[], or raw collections then you stick something in front of it to ensure the correct structure is passed down from the area you are working on.
    Again, not a good argument. Compiler warnings are there to indicate pitfalls.

    You could extend your argument to say that compiler warnings are unnecessary. In the real world, that is not practical.

    But it is valid. It is also unsound.
    It is quite possible for code to be both.
    I like the philosophical sleight of hand, which is a basic example of the sophistry that is the topic of the thread.

    You are essentially saying that the statement follows validly from a false premise. Where is that false premise, if not in the same statement?

  6. #46
    JosAH's Avatar
    JosAH is online now Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,386
    Blog Entries
    7
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    Not a good argument. The developer should not have to know if legacy code "uses Object[] inside of it".
    That all depends on the 'quality' of the legacy code; 'quality' changes over time. especially if it was written when no generics were around. Allowing raw types next to parameterized types allows that legacy code to still exist, no matter the 'heap pollution' you keep on babling about while not showing us a few real world examples that clearly show your problem. Applying the oppposite of Occam's razor doesn't help you either to help us solve your 'problem'.

    Jos
    KevinWorkman likes this.
    cenosillicaphobia: the fear for an empty beer glass

  7. #47
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,863
    Rep Power
    19

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    Not a good argument. The developer should not have to know if legacy code "uses Object[] inside of it".
    I'm sorry, but if you are developing against code that no one who works there knows how it works anymore, and it is sufficiently old to be suspect in its ways, then you screen it off.
    In any case...you won't be recompiling it, so you won't get any compilation warnings about problems internal to it, so your point is moot.
    And as I said, any change to how the runtime functions is rather unlikely.

    Quote Originally Posted by 2by4 View Post
    Again, not a good argument. Compiler warnings are there to indicate pitfalls.
    So essentially you are suggesting flagging a call into a method that takes a raw type as a parameter.
    That's it?

    Quote Originally Posted by 2by4 View Post
    You could extend your argument to say that compiler warnings are unnecessary. In the real world, that is not practical.
    Not saying that at all. I just don't see adding one for a valid use as above (calling a method that has a raw type as a parameter) is not helpful. After all, what can the coder do about it? Warnings are there for things you might be able to change.

    Quote Originally Posted by 2by4 View Post
    I like the philosophical sleight of hand, which is a basic example of the sophistry that is the topic of the thread.

    You are essentially saying that the statement follows validly from a false premise. Where is that false premise, if not in the same statement?
    There are lots of things you can do in code.
    Not all of it is sound.
    That does not mean it is the compilers job to flag it, or class it as invalid.

    No sophistry at all.
    KevinWorkman likes this.

  8. #48
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by JosAH View Post
    That all depends on the 'quality' of the legacy code; 'quality' changes over time. especially if it was written when no generics were around. Allowing raw types next to parameterized types allows that legacy code to still exist, no matter the 'heap pollution' you keep on babling about while not showing us a few real world examples that clearly show your problem. Applying the oppposite of Occam's razor doesn't help you either to help us solve your 'problem'.

    Jos
    When you don't understand a concept, you have this habit of blaming people for babbling. Why not just read up on the topic?

    I won't put live code here, simple. I have created an example based on real life scenarios.

    As far as solving the problem is concerned, I acknowledge the issues of instablilty. We don't even need a runtime solution at this point, and any solution can be phased in. The compiler can start by flagging ANYWHERE where there is a mix of raw and parametrized types/type parameters.

    Object o = new List<String> l;

    is really saying..

    Object<Object> o = new List<String> l;

    So what was once universally valid, no longer is when there is a mix. Why not flag it, rather than persist with its validity? It should be straight forward.

  9. #49
    JosAH's Avatar
    JosAH is online now Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,386
    Blog Entries
    7
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    When you don't understand a concept, you have this habit of blaming people for babbling. Why not just read up on the topic?
    I have been potty trained for years when generics saw the light and I understand what it's all about, unlike you. This forum is not about 'winning' a discussion as you assume; it is about solving a problem posted by an OP. You like to obfuscate matters and vague Mr-Know-It-All babbling. You're free to do so, but please don't do it here.

    Jos
    KevinWorkman likes this.
    cenosillicaphobia: the fear for an empty beer glass

  10. #50
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by JosAH View Post
    I have been potty trained for years when generics saw the light and I understand what it's all about, unlike you. This forum is not about 'winning' a discussion as you assume; it is about solving a problem posted by an OP. You like to obfuscate matters and vague Mr-Know-It-All babbling. You're free to do so, but please don't do it here.

    Jos
    OK, yet another totally empty personal whinge and no technical input.

    Bye!

  11. #51
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    It has become very clear to me where the inconsistency is. It is reminiscent of the old circle-ellipse problem.

    Is Circle a type of Ellipse. The problem centres around Ellipse.stretch().

    Some people argue that Circle.stretch() should override Ellipse.stretch() and deal with the constraint issue, e.g by throwing an exception.

    Others argue that Circle is not a type of Ellipse.

    Now the JLS says that..

    List<String> is not a type of List<Object>

    Even though String is a type of Object, the same is not the case for the container type. After all, you can put an Integer into the List<Object>, but not the List<String>.

    So

    List<String> ls = new ArrayList<>();
    List<Object> lo = ls; // Compile time error! incompatible types!

    But what about arrays? Is String[] a type of Object[]?

    Here, the JLS takes the other approach and says, "yes it is!" and deals with the problem by throwing a runtime exception if you put something other than a String in a String[].

    String[] sArr = new String[10];
    Object[] oArr = sArr; // OK!
    oArr[0] = new Integer(2); // Runtime error! ArrayStoreException!

    Clearly, they were forced into this inconsistency because they were unable to put the runtime checks in place for generics.

    So, what can happen is that you can slalom past the validation using arrays to sneak past the compile time checks and generics to avoid the runtime checks. Biko, you have heap pollution!

    And it is down to inconsistency of what is being termed "valid".

  12. #52
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    I'm sorry, but if you are developing against code that no one who works there knows how it works anymore, and it is sufficiently old to be suspect in its ways, then you screen it off.
    In any case...you won't be recompiling it, so you won't get any compilation warnings about problems internal to it, so your point is moot.
    And as I said, any change to how the runtime functions is rather unlikely.
    I am referring to code that can be fixed. The compiler is not as helpful as it could be.

    Quote Originally Posted by Tolls View Post
    So essentially you are suggesting flagging a call into a method that takes a raw type as a parameter.
    That's it?
    No. See my last post. They should be consistent about what they are calling "valid". Until and unless they can put in the runtime checks, they should flag array conversions at compile time when necessary, to warn against heap pollution. String[] is a subtype of Object[] can be said to be valid only if you are covered by a runtime check. Generics means that this validity is not universal.

    Not saying that at all. I just don't see adding one for a valid use as above (calling a method that has a raw type as a parameter) is not helpful. After all, what can the coder do about it? Warnings are there for things you might be able to change.
    See my last post, and the problem with you calling it valid.

    There are lots of things you can do in code.
    Not all of it is sound.
    That does not mean it is the compilers job to flag it, or class it as invalid.

    No sophistry at all.
    You didn't answer the question. Which line contains the false premise that makes the statement unsound?

  13. #53
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,863
    Rep Power
    19

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    I am referring to code that can be fixed. The compiler is not as helpful as it could be.
    If the code can be fixed (ie it is being worked on) then fix it. If not then screen it.
    That's it.
    Don't just sit back and complain that, because the code is doing something unsound something somewhere should tell you.
    After all, if you're compiling it you are working on it.

    Quote Originally Posted by 2by4 View Post
    No. See my last post. They should be consistent about what they are calling "valid". Until and unless they can put in the runtime checks, they should flag array conversions at compile time when necessary, to warn against heap pollution. String[] is a subtype of Object[] can be said to be valid only if you are covered by a runtime check. Generics means that this validity is not universal.

    See my last post, and the problem with you calling it valid.
    Array casting has always been valid, due to the nature of arrays as defined in the first JLS. That is the elements can be cast (similar to C++ IIRC).

    Generics are a different beast. A List<String> is not a List<Object>, there is more to them than simply a load of references stuck together. The same (again IIRC) would apply in C++ with the relevant template.

    Quote Originally Posted by 2by4 View Post
    You didn't answer the question. Which line contains the false premise that makes the statement unsound?
    As for the valid and unsound thing, I have no idea what you're going on about now.
    You said:
    "
    An assignment to Object, which you have said is ALWAYS valid, is described here as "unsound".
    "
    Yes. Because the valid applies to what is allowed in the language. The unsound applies to whether it is a good idea to abuse the language in such a way.
    So it is both valid (in terms of the language specification) and unsound.

    All programming languages have things which are valid (as in allowed by their specification) and are unsound (as in not a good idea to do). Every language has its code smells. All the ones I have worked in had them.
    KevinWorkman likes this.

  14. #54
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    As for the valid and unsound thing, I have no idea what you're going on about now.
    Look up the actual meaning of the word "sound" w.r.t logic, instead of the one you made up. Then you will know.

    Quote Originally Posted by Tolls View Post
    Yes. Because the valid applies to what is allowed in the language. The unsound applies to whether it is a good idea to abuse the language in such a way.
    So it is both valid (in terms of the language specification) and unsound.
    Is that it? You think we have been discussing whether or not the JLS says something is valid?

    That is not what my thread is about. I am saying the JLS implementation is inconsistent and invalid, regardless of what it says.

    Quote Originally Posted by Tolls View Post
    If the code can be fixed (ie it is being worked on) then fix it. If not then screen it.
    That's it.
    Don't just sit back and complain that, because the code is doing something unsound something somewhere should tell you.
    After all, if you're compiling it you are working on it.
    Fortunately, the improvements that they have made in Java 7 suggest that they do not totally share your "sweep it under the carpet" attitude.

    Quote Originally Posted by Tolls View Post
    Array casting has always been valid, due to the nature of arrays as defined in the first JLS. That is the elements can be cast (similar to C++ IIRC).

    Generics are a different beast. A List<String> is not a List<Object>, there is more to them than simply a load of references stuck together. The same (again IIRC) would apply in C++ with the relevant template.
    (IIRC = If I remember correctly, for anyone unfamiliar with the acronym)

    Again, you advance a circular argument. i.e "they are a different beast because that is how Java has implemented them and therefore that is how Java has implement them".

    Bottom line is that you defer uncritically to the JLS and its implementation.

    Correct, C++ does treat arrays and templates differently, but I can find you documentation that will tell you clearly and unequivocally that this is because of the overhead of additional runtime checks for inheritance, and not anything essentially or intrinsically different in the two types.

    Also, C++ does not have the heap pollution issues, because it does have runtime checks for generic types, simply by the dint of the fact that it doesn't use type erasure.
    Last edited by 2by4; 12-21-2011 at 07:07 PM.

  15. #55
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,863
    Rep Power
    19

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    Look up the actual meaning of the word "sound" w.r.t logic, instead of the one you made up. Then you will know.

    Is that it? You think we have been discussing whether or not the JLS says something is valid?
    That is not what my thread is about. I am saying the JLS implementation is inconsistent and invalid, regardless of what it says.
    You're doing it again. As with "pass by value" things in software have meaning. Something can be valid syntactically (as per the JLS in other words), which is what that "Valid" means. It may also be unsound in terms of it being a sensible thing to do. If you cannot speak the lingo then please don't attempt to argue against it.
    You questioned how they could call something both valid and unsound...I explained what they were talking about. That you do not seem to understand the technical terms in s technical field is hardly my fault.
    Or are you going to accuse me of thinking "too low level"?

    Quote Originally Posted by 2by4 View Post
    Fortunately, the improvements that they have made in Java 7 suggest that they do not totally share your "sweep it under the carpet" attitude.
    And if Project Coin could have done what you are suggesting with little disruption I'm sure they would have...instead they managed to provide some additional warning on varargs on declaration.

    Quote Originally Posted by 2by4 View Post
    (IIRC = If I remember correctly, for anyone unfamiliar with the acronym)

    Again, you advance a circular argument. i.e "they are a different beast because that is how Java has implemented them and therefore that is how Java has implement them".

    Bottom line is that you defer uncritically to the JLS and its implementation.

    Correct, C++ does treat arrays and templates differently, but I can find you documentation that will tell you clearly and unequivocally that this is because of the overhead of additional runtime checks for inheritance, and not anything essentially or intrinsically different in the two types.

    Also, C++ does not have the heap pollution issues, because it does have runtime checks for generic types, simply by the dint of the fact that it doesn't use type erasure.
    Because C++ evolved differently.
    Java made design decisions from the beginning that continue to have an effect.
    Lack of generics (unlike C++ and templates from the beginning) meant there was no mechanism for adding them in another way without breaking the existing code. Read the JSR on it to see what I mean.

  16. #56
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    You're doing it again. As with "pass by value" things in software have meaning.
    Exactly, and you should try to understand variation in usage instead of insisting on a narrow viewpoint. As my links showed, some very accomplished people share my point of view on "pass by value". Unlike you, I have taken the broad perspective and recognised both usages.

    Quote Originally Posted by Tolls View Post
    Something can be valid syntactically (as per the JLS in other words), which is what that "Valid" means. It may also be unsound in terms of it being a sensible thing to do. If you cannot speak the lingo then please don't attempt to argue against it.
    "Valid" in the given context means "semantically correct" not "syntactically correct".

    "Unsound" means based on an assumption (premise) that is not (necessarally) true.

    Again, it is you who doesn't know where the lingo comes from.

    You questioned how they could call something both valid and unsound...I explained what they were talking about. That you do not seem to understand the technical terms in s technical field is hardly my fault.
    Or are you going to accuse me of thinking "too low level"?
    See above. And yes, I would add "narrow" to "low level". Nothing wrong with low level; it's a technical term, (huh?) used when talking about layered architectures, processes or methodologies.

    Quote Originally Posted by Tolls View Post
    And if Project Coin could have done what you are suggesting with little disruption I'm sure they would have...instead they managed to provide some additional warning on varargs on declaration.

    Because C++ evolved differently.
    Java made design decisions from the beginning that continue to have an effect.
    Lack of generics (unlike C++ and templates from the beginning) meant there was no mechanism for adding them in another way without breaking the existing code. Read the JSR on it to see what I mean.
    That is fine, and that is what the documentation should say, rather than pretend the design is a result of logical analysis of the underlying requirement. But, as your argument seems to stop at that level, I understand why you thought I was asking you what was contained in the JLS, and why you kept repeating it.

    You honestly thought I was asking if the JLS says that you can assign any reference type to an object?

    Clearly you have discovered that the question is a little deeper, and also, in your own words, such assignments are "open to abuse" in certain scenarios. Those scenarios are not currently flagged, and they should be.
    Last edited by 2by4; 12-22-2011 at 12:57 PM.

  17. #57
    JosAH's Avatar
    JosAH is online now Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,386
    Blog Entries
    7
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    As my links showed, some very accomplished people share my point of view on "pass by value".
    You must be from another planet and bluffing doesn't intimidate us one bit; go and study the nuts and bolts first before you start babbling about 'broad perspectives'.

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  18. #58
    KevinWorkman's Avatar
    KevinWorkman is offline Crazy Cat Lady
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    3,889
    Rep Power
    8

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by JosAH View Post
    You must be from another planet and bluffing doesn't intimidate us one bit; go and study the nuts and bolts first before you start babbling about 'broad perspectives'.

    Jos
    The OP has done this over at javaprogrammingforums.com, as well. I'm pretty sure he's a troll, using his half-complete understanding of Java to start fights about mostly nonsensical things. He then shifts his argument whenever anybody explains to him why his assumptions are invalid. I'm impressed you guys have had the patience to put up with him this long, because there is no way he's going to concede anything, even when he has been outright proven to be wrong.
    How to Ask Questions the Smart Way
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  19. #59
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Damn! Another moderator (from another site) who thinks moderator = "always right" and can't hack it when they are challenged and proven wrong.

    On that other forum, when I indicated that I would only browse and no longer post, this same KevinWorkman wanted me to continue my thread aimed at encouraging newbies. A strange and hypocritical thing to be asking of someone you say is a troll. Stop the childishness and long sulk please and get over being challenged and proven wrong.

    Address the points in the thread.

    (PS I am not including Tolls, here. I have no issue with aggressive and critical line of argument that is on topic and not purely personal).

  20. #60
    JosAH's Avatar
    JosAH is online now Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,386
    Blog Entries
    7
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    If that 2by4 continues like this I'll ban him. His posts/replies are of no value at all.

    Jos
    cenosillicaphobia: the fear for an empty beer glass

Page 3 of 5 FirstFirst 12345 LastLast

Similar Threads

  1. Type Erasure
    By Lil_Aziz1 in forum New To Java
    Replies: 3
    Last Post: 06-29-2010, 08:57 AM
  2. min / max and documentation
    By jon80 in forum New To Java
    Replies: 1
    Last Post: 04-20-2008, 12:37 PM
  3. documentation
    By mcal in forum New To Java
    Replies: 4
    Last Post: 02-07-2008, 06:20 AM
  4. Java Documentation
    By ravian in forum New To Java
    Replies: 4
    Last Post: 12-04-2007, 09:45 AM
  5. ArrayList<type> - Generics
    By Java Tip in forum Java Tip
    Replies: 0
    Last Post: 11-14-2007, 03:21 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •