Syntactic Sugar for Lists and Maps

Discussions

News: Syntactic Sugar for Lists and Maps

  1. Syntactic Sugar for Lists and Maps (53 messages)

    List and map literals should be a really simple addition to Java, but Java's static types and generics can cause some difficulty here. Stephen Colbourne presents some syntactic sugar that might help developers work with lists and maps. Instead of the rather verbose and redundant: List emptyList = new ArrayList(); we could write: List emptyList = []; Also, for adding items to a list, where you currently would use: List list = new ArrayList(); list.add("Abba"); list.add("Beatles"); list.add("Corrs"); we could write: List list = ["Abba", "Beatles", "Corrs"]; One of the readers of his blog posted that we can already achieve that in the current version of Java with (in this case, the list is unmodifiable): List list = Arrays.asList("Abba", "Beatles", "Corrs"); The advantage of this syntactic sugar is that we do not need to add new keywords to the language. It is easier for beginners to read, but it also means they have more options of doing the same thing. You can read the full post here.

    Threaded Messages (53)

  2. List emptyList = new ArrayList() is pretty anoying indeed so i vote for relaxization here. ArrayList emptyList = new ArrayList() is actually more verbose than necessary so lets take this further and propose this for every new object creation. AnyClass anyObject = [] would be great for default construction of new objects that are of the same type as the variable they are stored in.
  3. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    List emptyList = new ArrayList() is pretty anoying indeed so i vote for relaxization here.

    ArrayList emptyList = new ArrayList() is actually more verbose than necessary so lets take this further and propose this for every new object creation.

    AnyClass anyObject = [] would be great for default construction of new objects that are of the same type as the variable they are stored in.
    Original syntex is much more better than this one.... its hell -1 Sudhir Nimavat
  4. List emptyList = [];
    Even better: emptyList = new List(); Since the type is on the right, the compiler can make out what type emptyList is. You could do this for everything. There really is no good reason to have the type on both sides of the condition. I don't see this or any other thing mentioned here done to Java until it is way too late. Java is a captive of its own audience.
  5. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    emptyList = new List();
    Definitely not better unless you add a var keyword or something. Otherwise you get python all over again where making a typo creates a new variable (though the compiler would catch most of it). Besides, List is an interface, and even I'm not too comfortable with the idea of a "default implementation", which I suppose also creates a problem with literals. Using a statically imported vararg utility method seems to be the most elegant way, but alas those break in the face of overloads and generics. Anyway, I'm no longer all that comfortable with map literals, since I prefer that objects I sling around with named fields have labels that are staticly checked. This means some kind of initializer syntax. Something I also don't see Java getting, because it's too dangerously close to being expressive and useful (yeah, bitter much?)
  6. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    Definitely not better unless you add a var keyword
    You don't need the "var" keyword since we have the "new" keyword. I kept thinking something like putting a "def" keyword in there would make it more readable but decided to just drop that too.
    Besides, List is an interface
    I was only following the articles examples. Replace "List" with something like "ArrayList". By the way, the other day I was fixing someones code that looked like this (which is valid): Collection a = new ArrayList(); This is what got me to asking "why the heck do we define the type on the left when it really doesn't do anything for us?"
    it's too dangerously close to being expressive and useful (yeah, bitter much?)
    Yeah, feel the same. I've moved on to looking at other languages because of this. Many purists will just yell "fine, go away and leave my perfect Java alone", but what they really are saying is "I don't want to learn anything new because it scares me".
  7. Re: Syntactic Sugar for Lists and Maps[ Go to top ]


    Definitely not better unless you add a var keyword


    You don't need the "var" keyword since we have the "new" keyword. I kept thinking something like putting a "def" keyword in there would make it more readable but decided to just drop that too.


    Besides, List is an interface


    I was only following the articles examples. Replace "List" with something like "ArrayList". By the way, the other day I was fixing someones code that looked like this (which is valid):

    Collection a = new ArrayList();

    This is what got me to asking "why the heck do we define the type on the left when it really doesn't do anything for us?"


    it's too dangerously close to being expressive and useful (yeah, bitter much?)


    Yeah, feel the same. I've moved on to looking at other languages because of this. Many purists will just yell "fine, go away and leave my perfect Java alone", but what they really are saying is "I don't want to learn anything new because it scares me".
    Says you. I would say that perhaps they think this is not all that important an item. I've never heard anyone say java is perfect.
  8. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    I was only following the articles examples. Replace "List" with something like "ArrayList". By the way, the other day I was fixing someones code that looked like this (which is valid): Collection a = new ArrayList(); This is what got me to asking "why the heck do we define the type on the left when it really doesn't do anything for us?"
    Left side = interface, right side = implementation. If usage pattern changes, so you have many add or removes inside list, you can change ArrayList() to LinkedList() without other changes required and get a nice performance gain.
  9. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    Left side = interface, right side = implementation.
    String a = new String("test"); Left side does not have to be an interface.
    you can change ArrayList() to LinkedList() without other changes required and get a nice performance gain.
    Or just your IDE's replace command (or awk for those who like the command line). Really, how hard is it to change "a = new ArrayList" to "a = new LinkedList"?
  10. Yeah, feel the same. I've moved on to looking at other languages because of this. Many purists will just yell "fine, go away and leave my perfect Java alone", but what they really are saying is "I don't want to learn anything new because it scares me".
    Many would say leave Java alone, we'd rather start from scratch with a new language that is smoothly compatible with existing Java libraries. Sometimes it is best to leave the baggage behind.
  11. Ooops, I forgot to put this in:
    List list = ["Abba", "Beatles", "Corrs"];
    would become: list = new List(){"Abba", "Beatles", ... }; The functionality to add items like this should only be for Lists. For maps (HashMap, etc): map = new Map(){{"A","1"}, {"B","2"}}; That should do it. So in all: 1. make the type declaration on the left optional (make old code still work this way) 2. for new code we can use the new way of populating maps and lists. Not much, but it helps :)


  12. Instead of the rather verbose and redundant:

    List emptyList = new ArrayList();

    we could write:

    List emptyList = [];

    How would that work? List is an interface. What class should the compiler/VM choose to create an instance of?


  13. Instead of the rather verbose and redundant:

    List emptyList = new ArrayList();

    we could write:

    List emptyList = [];



    How would that work? List is an interface. What class should the compiler/VM choose to create an instance of?
    The compiler would have to use "sensible defaults." I think it would be better to force using a concrete class in the variable declaration. I think it's better to forgoe coding to an interface instead of implementation than to have the compiler picking types for you. That being said, while I think these features are eminently convenient in scripting languages, I don't think it belongs in Java. Maybe an easy compromise would be to make constructors for all the collections classes that will create a collection from an array.
  14. Agreed[ Go to top ]

    I think it would be better to force using a concrete class in the variable declaration. I think it's better to forgoe coding to an interface instead of implementation than to have the compiler picking types for you.
    Don't forget, if you use javax.xml, you are essentially coding to the interface. Then at runtime you can tell Java if you want to use a different implementation. I always thought it would be nice to do a similar thing with collections, although the factory mentality is a pain in the arse. (Yes, I understand _why_ it is that way, but that doesn't make it any easier to use.)
    That being said, while I think these features are eminently convenient in scripting languages, I don't think it belongs in Java.
    Indeed. JRuby or Groovy please. If you want these features, just code it in Groovy and just compile it to Java classes.
  15. Maybe an easy compromise would be to make constructors for all the collections classes that will create a collection from an array.
    You mean like List _list = new SomeListImpl(Arrays.asList(new String[] {"foo", "bar"})); I don't see the benefit of those constructors you are speaking of. They would only save you exactly 15 keystrokes. Regards, Dirk
  16. I don't see the benefit of those constructors you are speaking of. They would only save you exactly 15 keystrokes.
    Sounds like you pretty much understand the productivity benefit. There's also the benefit of possibly quelling some complaints from people who want to make Java a scripting language without actually making Java a scripting language or doing any damage to the language or library. Being able to pass an array to a collections constructor would occasionally be useful. Of course it would be much less useful if libraries entered the 21st century and stopped using arrays as parameters/return types.
  17. Looks like a bunch of hacks[ Go to top ]

    If you want a script language, go use Perl or Ruby, leave Java alone.
  18. Re: Looks like a bunch of hacks[ Go to top ]

    If you want a script language, go use Perl or Ruby, leave Java alone.
    +1
  19. Re: Syntactic Sugar[ Go to top ]

    Stephen Colbourne presents some syntactic sugar that might help developers work with lists and maps.
    Pleasssseeee. If developers have got problems with instantiating a List or a Map in Java they really should consider an alternative language, or profession maybe. Oh nooo, I'm starting to sound like the biler. How do I instantiate an empty LinkedList with this gibberish ? Ahh right, I cant? ok. Talk about trying to confuse people. I gave up on "sugar" years ago when I realised it was bad for the teeth.
    Maybe an easy compromise would be to make constructors for all the collections classes that will create a collection from an array.
    Exactly.
  20. Re: Syntactic Sugar[ Go to top ]

    I gave up on "sugar" years ago when I realised it was bad for the teeth.
    First of all I dont believe you gave up on sugar and if you brush 2 times a day your theeth will stay just fine. And dont forget to floss ;)
  21. Re: Syntactic Sugar[ Go to top ]

    If developers have got problems with instantiating a List or a Map in Java they really should consider an alternative language, or profession maybe.
    They do, in fact. Won't Java just be perfect when no one is left who actually wants to use it?
  22. Re: Syntactic Sugar[ Go to top ]

    If developers have got problems with instantiating a List or a Map in Java they really should consider an alternative language, or profession maybe.


    They do, in fact. Won't Java just be perfect when no one is left who actually wants to use it?
    Yup. Java will end up dead like C++ and COBOL. Completely abandonned with no working software left written in them. Oh, wait a minute... Conceptual integrity in a programming language is important. I think throwing all sorts of features into Java will break its conceptual integrity. Why not leave Java alone (or evolve it slowly) and start focusing on Groovy, or a new clean language without all the baggage?
  23. Sugar is Good for you[ Go to top ]

    I am in completely agreement with making basic types such as Lists and Maps feel more natural in Java. List myList = [] myList[0] = 'howdee'; Map myMap = {}; myMap['key'] = 'value'; These are nice for usability at the expense of making spec people and compiler writers work harder (but I don't care about them :) ), and are good for productivity.
  24. Re: Sugar ROTS your Teeth[ Go to top ]

    making basic types such as Lists and Maps feel more natural
    What is "feel more natural" ? Wishy washy term used by the ruby glowstick brigade perhaps?
    These are nice for usability at the expense of making spec people and compiler writers work harder
    Or perhaps you just get a decent IDE, and have the IDE do that for you, so the code remains readable and intelligible, where you dont limit your syntax to only a particular implementation of a List or Map. There was me thinking that each of the different implementations has benefits in particular situations, and people should use the relevant one for their situation. In this SugarInfestedWorld you'd have ArrayList and HashMap and nothing else.
  25. While I'm usually against 'syntactic sugar' which sacrifices language coherency to save us a few keystrokes, I think this is something different. Java claims to be an object-oriented language, but object literals are few and far between. String and Class are the only ones which come to mind. Other OO languages embrace objects more completely, allowing for a richer set of object literals. For example, in Ruby, object literals are common: 1 # Fixnum "a" # String [0,2,3] # Array, like java.lang.ArrayList {0=>2,1=>3} # Hash, like java.lang.HashMap /aaa/ = # Regexp 2..5 # Range :abc # Symbol The given example of 'List myList = ["a","b"];' is a bit unfortunate because adds other dimensions to the question. It uses an interface type on the left-hand side and uses generics. Let's build up to his example: // Example 1 ArrayList myList = ["a","b"]; This should prevent no problem if ["a","b"] is the literal form of an ArrayList. // Example 2 List myList = ["a","b"]; We're just assigning an ArrayList to a List, so the compiler isn't doing any guessing. // Example 3 List myList = ["a","b"]; I don't see any problem here, either, but I'm no expert on generics. I would think the compiler could understand that the in the variable declaration applies to the literal ArrayList as well. However, I'm not 100% sure on that. Interestingly, String and Class are final in java. I'm sure there are many reasons for that apart from the fact that they can be expressed as literals. But suppose they weren't final. Wouldn't you expect the following to work (provided appropriate constructors were in place)? EnhancedString s = "aaa"; EnhancedClass c = Foo.class;
  26. Oops - forgot about one thing[ Go to top ]

    Oops - forgot about one thing: Another dimension was added to the question since the original poster uses "[]", which is already reserved for Arrays. We might want some other syntax, such as: List myList = {"a","b"};
  27. Oops - forgot about one thing[ Go to top ]

    Scratch that. I had "[]" and "{}" backward in my head, so my original post was right. I've been away from Java for a few months.
  28. List aList = new ArrayList(){{ add("a"); add("b"); add("c"); }}; Map aMap = new HashMap(){{ put("a", "b"); put("b", "c"); }}; Not as nice as aList = ["a", "b", "c"] or aMap = {"a" => "b", "b" => "c"} but it will do.
  29. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    The part that frustrates me with this type of discussion is that the collections that are part of the JDK are not the end all of collections. If you want to add behavior to a collection, then extend an existing one. Creating custom collections is not hard and can make your life so much easier. How about making a collection defined like this: public class MyArrayList extends ArrayList and then make a constructor like this: public MyArrayList(O... initialObjects){ for(O initialObject : initialObjects){ add(initialObject); } } now you can do the following: List mal = new MyArrayList("Abba", "Beatles", "Coors"); So why do we need to add new things to the JDK? John Murray Sobetech
  30. syntactic sugar[ Go to top ]

    A similar conversation is going on over at http://www.infoq.com/news/2007/02/railsanswer Feb 20, 2007 2:13 PM by Marc Stock is a great response. Java needs syntactic sugar and to be "sexy" to attract and keep new people. Otherwise over time it is likely to become more and more niched. With your approach, it's just more for a new developer to learn, whereas it's its so much simpler in the other languages. Most people don't "realize" that Java's rigidness and plainness (and what has been built with it) is what makes it sexy. But at the same time, in other conversations, particularly http://www.artima.com/forums/flat.jsp?forum=106&thread=194961, developers have admitted if Java had done some things differently from the start, it would be a better language, and it may even be "too late" to correct these problems while maintaining backwards compatibility. Making JRuby, Jython, etc high performance and seamless on top of the JVM is probably the best solution. Then the world can be CLR vs JVM. :)
  31. Arrays.asList() isn't unmodifiable.[ Go to top ]

    Do try this at home. List list = Arrays.asList("Abba","Beatles","Corrs"); System.out.println("Before set() List="+list); list.set(1, "Beach Boys"); System.out.println("After set() List="+list);
  32. Do try this at home.

    List list = Arrays.asList("Abba","Beatles","Corrs");
    System.out.println("Before set() List="+list);
    list.set(1, "Beach Boys");
    System.out.println("After set() List="+list);
    According to the documents you cannot add/delete elements. It's just a wrapper for the array. So if you change the underlying array you also change the contents of the list.
  33. Do try this at home.

    List list = Arrays.asList("Abba","Beatles","Corrs");
    System.out.println("Before set() List="+list);
    list.set(1, "Beach Boys");
    System.out.println("After set() List="+list);


    According to the documents you cannot add/delete elements. It's just a wrapper for the array. So if you change the underlying array you also change the contents of the list.
    The issue is that you can't specify the list type so you can't have an Arrays.asList that results in say an instance of ArrayList. Nothing is stopping you from creating your own utility method to do the same thing in a more flexible way. List li = ArrayUtil.asArrayList("this", "that", .. "the other"); I haven't found the missing sugar a big problem. What would be nice is a super easy way to inline a scripting language so if you wanted to be super type-safe you'd use regular Java but when you wanted to be loosy-goosy then you'd drop into scripting. I don't know if this is possible to do cleanly or even a good idea but it would solve the appetite for more concise code without over-polluting the Java language.
  34. I don't know if this is possible to do cleanly or even a good idea but it would solve the appetite for more concise code without over-polluting the Java language.
    +1
  35. How about: List list = new ArrayList(); Collections.addAll(list, "aaa", "bbb", "ccc"); ...at least you don't have to create the array object.
  36. good or bad??[ Go to top ]

    It is easier for beginners to read, but it also means they have more options of doing the same thing.
    And who said this is good???
  37. I fail to see the usefullness[ Go to top ]

    I have no troubles with Maps or Lists in Java. In fact, I love Java for the fact that creating new list is consistent with creating a new object - which is what it is. I'm already a bit unfriendly towards new loops as all they do is bring Java's simple and consistent syntax closer and closer to one in Perl. Yes, this looks good. But what is the point? How exactly does it benefit the developer? This kind of information is trivial and serves no real purpose. When I'm debugging the code while holding a client on the phone I don't look into how the list was created; it doesn't matter; my eyes expect text to be written in certain way. Having yet another syntax would make it harder to read. Just my opinion. Keep Java clean.
  38. Re: I fail to see the usefullness[ Go to top ]

    Forgot to add: I like hiding my implementations: public List getStringQueue() { List items; if (singleThread) items = new LinkedList(); else items = new CopyOnWriteArrayList(); items.add("bummer"); return items; } And another thing. How would you do custom objects? List or Map> ????
  39. Syntactic sugar[ Go to top ]

    Bad idea. In my opinion most "improvements" of Java5 were allready a step in the wrong direction. Remove autoboxing. Remove new loops. Not sure how i feel about annotations. Keep templates. Add byte literals. Stop changing bytes to ints whenever you get the chance. Remove + for String literals.
  40. Re: Syntactic sugar[ Go to top ]

    Bad idea.
    In my opinion most "improvements" of Java5 were allready a step in the wrong direction.
    Remove autoboxing.
    Remove new loops.
    Not sure how i feel about annotations.
    Keep templates.
    Add byte literals.
    Stop changing bytes to ints whenever you get the chance.
    Remove + for String literals.
    Almost agree: Keep new loops Remove autoboxing AND Remove "simple" types Remove templates (and kick ass if developers don't write documentation) Go back to providing good, concise and exact documentation. Please leave me alone with resorting more and more "documentation by example" that creeps into more and more Java libraries (some JEE 1.5 elements come to mind).
  41. 1 - I just love autoboxing, and i don't see anything wrong in it, philosophically speaking. 2 - IMHO, one of the huge advantage of Java is that it's a STRONGLY typed language. Mixing arrays and list (wich are objects !) can be confusing. Everything in its right place. 3 - If you don't like it, go Ruby!
  42. Problem with autoboxing[ Go to top ]

    The problem with autoboxing is that it happens even if not wanted. For instance, suppose that I have a class with an int instance variable, and a getter and setter for this variable. Suppose that I discover that this property, coming from the database, might in fact be null. No problem: I change the instance variable type to Integer. In Java 1.4 and before, I will have a compilation error, because I have to change the getter and setter to use Integer as well. In Java 5, no compilation error because of autoboxing. But if I call the getter and the property is null, I get a NullPointerException. Autoboxing has the reverse effect of generics: it makes the code less type-safe, and more error-prone. I also vote for the removal of autoboxing.
  43. Re: Problem with autoboxing[ Go to top ]

    I would argue that the problem with nulls and autoboxing goes to a more basic problem: null. Its very existence is dubious, the source of probably half the unexpected exceptions in Java if not much more. I vote for the removal of null except as allowed explicitly. What I suspect we may get instead is a @NotNull annotation that will totally fail to have any kind of type inference, so you'll have to use it *everywhere* to make it actually work.
  44. Re: Problem with autoboxing[ Go to top ]

    I would argue that the problem with nulls and autoboxing goes to a more basic problem: null. Its very existence is dubious, the source of probably half the unexpected exceptions in Java if not much more.

    I vote for the removal of null except as allowed explicitly. What I suspect we may get instead is a @NotNull annotation that will totally fail to have any kind of type inference, so you'll have to use it *everywhere* to make it actually work.
    yeah you are right, I was very happy with autoboxing until I ran into some bugs that where really hard to resolve and originated from an Integer being null.
  45. Java is strongly typed, that is right - but no too verbose to avoid developers feel like repeating always and always things. By the way, nobody should complain about Java now - generics are a great help. Or else, I will ask him/her to write Ada for a while !
  46. So as I was skimming through this thread, the syntactic sugar suggestions looked nice and useful. And then it occurred to me - would I even use them? Take this code for example:
    List list = new ArrayList(); list.add("Abba"); list.add("Beatles"); list.add("Corrs");
    I can't recall the last time I manually built a List (or Map for that matter) of objects in my code. I'm sure I have, I just don't do it very often. Most of the collections I use are populated at runtime. And typing
    List list = new ArrayList();
    really doesn't consume that much time for me. Maybe the one place where building collections by hand is commonplace is in unit tests. Even then, if this ugly code occurred very often if would probably be refactored to be captured in one place (e.g. test fixture, object mother). And besides, existing Java scripting languages like Groovy seem to scratch this itch for unit tests already. Now, I am not one to shun syntactic sugar - I love the new for loop. I just think that every new shortcut acts as a speed bump instead of an accelerator until your eye gets used to it. And I just don't think sweetening this code is worth it.
  47. I can't recall the last time I manually built a List (or Map for that matter) of objects in my code. I'm sure I have, I just don't do it very often.
    Good to hear, I was wondering if I was the only one. I actually know when I do it: for testing. Which is common, but not that frequent. My production code hardly ever uses inline initialization, so this whole debate leaves me a bit indifferent. As for the annoying construction redundancy, it's very easy to avoid: List list = ListUtils.newArrayList(); Implementation left to the reader. -- Cedric http://testng.org
  48. I actually know when I do it: for testing. Which is common, but not that frequent. My production code hardly ever uses inline initialization, so this whole debate leaves me a bit indifferent.
    I can't remember ever using inline initialization for arrays in Java code outside of tests but I do it all the time in Python. The benefit (or curse) is that it helps you blur the line between data and code. Not that it increases the capability but that making it easy to type makes you more likely to do it. It kind of occupies that grey area between what is code and what is configuration.
  49. I can't recall the last time I manually built a List (or Map for that matter) of objects in my code. I'm sure I have, I just don't do it very often.
    Good to hear, I was wondering if I was the only one.
    I agree. I populate lists in code: a) If they are immutable, in which case Arrays.asList() works fine. b) For tests, in which case I generally have some static initiatlization method because I reuse the lists in several different methods. I can't think of any other instances where I populated lists in production code.
  50. I can't recall the last time I manually built a List (or Map for that matter) of objects in my code. I'm sure I have, I just don't do it very often. Most of the collections I use are populated at runtime.
    Manual build is useful only for testing. Writing tests in Groovy look like good idea.
  51. Reply from blog author![ Go to top ]

    Well, I was a little surprised to find this posted here, but I'm glad of the additional discussion. However, there is some context: I've been writing a whole series of articles on possible language changes that could be added to Java 7. The main aim is to instigate debate and discussion, exploring what would happen if Java did make a specific change. (IMHO, this is a debate that Sun ought to be hosting in a more structured way, but that doesn't seem to be happening, so I'm trying to help the debate along.) At some point, I'll get to write up my conclusions on the responses I've seen to the various potential language changes. The amusing thing about this particular blog post being added on TSS is that the thread on my blog had already pretty much reached a conclusion that an API change is better than a language change for this. On specific comments here on TSS: - What would literals create? Yes, the syntax in the blog assumed ArrayList and HashMap (by design). That is of course one reason why these literals in Java don't work well. - Adding a varargs constructor to each collection implementation. If you code this, you'll find it doesn't work well. The problem is that method overloading, generics and varargs don't play nicely. (Try a method taking List... if you don't believe me) - Creating an anonymous subclass and calling add/put. This is IMHO an absolutely horrible hack. Sure its incredibly clever, but thats the problem - its a kind of showing off how clever you are. Certainly, anyone who hasn't been exposed to the pattern will get way confused. By the way, if you read the comments on my blog, you'll see that the general opinion is to go with this solution: List list = ArrayList.create("Abba","Beatles","Corrs"); The exact form for maps is trickier, but there are a couple of ideas floating about. Finally, I'd like to point out that the Java language has changed before (inner classes, assert, generics, boxing, enums, annotations,...), and almost certainly will change again. But how it changes is still up for grabs. If you want to influence the debate, get involved!
  52. Re: Syntactic Sugar for Lists and Maps[ Go to top ]

    You can use this trick to extend ArrayList and on construction add the members you like: List list = new ArrayList(){{add("element");}}; It's not the most elegant way, but in quick'n'dirty mode it does the thing tight.
  53. I think we should be thinking about sets too. My argument isn't because of a scripting background, but because of a Pascal background. It's very useful to be able to say, without lots of lines of code, "if x is in ( 1, 2, 5, 6), ..." In Java, this would take several lines of code: Set cases = new HashSet(); cases.add(1); cases.add(2); cases.add(5); cases.add(6); if (cases.contains(x)) { ... } which isn't at all intuitive; whereas this is much simpler and easier to understand: HashSet cases = [ 1, 2, 5, 6 ]; if (cases.contains(x)) { ... } It would be even nicer to be able to do: if (x in [ 1, 2, 5, 6]) { ... } but that probably wouldn't be acceptible to too many people! Incidentally, I don't think this has anything to do with the scripting vs compiled language debate. Sets, lists and maps are an everyday use of 3GL languages, so pretending that they should be difficult to use just because Java's not a scripting language is simply absurd. Pascal, as a language, is syntactically much superior to Java in its use of sets. You might just as well say Java shouldn't have bounds checking on arrays! or give proper stack traces! or have exception handling at all! Hey, why don't we just write in C? Btw, I have 7 years experience developing in Java, and about 4 years prior to that in Pascal (well, Delphi, actually), but I still miss some of the Pascal language features because they make the code more intelligible: it's easier to be able to communicate in code what your intentions are, and that is the key of good programming, IMO.
  54. Incidentally, I don't think this has anything to do with the scripting vs compiled language debate. Sets, lists and maps are an everyday use of 3GL languages, so pretending that they should be difficult to use just because Java's not a scripting language is simply absurd. Pascal, as a language, is syntactically much superior to Java in its use of sets.
    Agree that sets should be supported IF support is added. The issue is coupling between the language syntax and the compiler. If the type specified is an interface than the compiler has to assume a concrete implementation that should be used. For the simple cases you can assume Set => HashSet and SortedSet => TreeSet. As a side note, this would mean the Collections interfaces and classes would need to be moved from java.util to java.lang in order to maintain consistency.