1 2 3 4 Previous Next 45 Replies Latest reply: Jul 12, 2010 10:44 AM by 843789 RSS

    Map Interface

    843789
      I understand Set & List extends the Collection interface, but why doesn't the same hold true for the Map interface? Is there any specific design constraint?
        • 1. Re: Map Interface
          gimbal2
          Answer yourself this then: how COULD the Map derive from Collection?

          You'll find that it simply isn't possible because maps work on key/value pairs and Collection classes do not.
          • 2. Re: Map Interface
            843789
            MaxisAlexis wrote:
            I understand Set & List extends the Collection interface, but why doesn't the same hold true for the Map interface? Is there any specific design constraint?
            A Map could easily have been viewed as a Collection of Pairs. I think C# took that road actually.
            • 3. Re: Map Interface
              3004
              wastrel wrote:
              MaxisAlexis wrote:
              I understand Set & List extends the Collection interface, but why doesn't the same hold true for the Map interface? Is there any specific design constraint?
              A Map could easily have been viewed as a Collection of Pairs. I think C# took that road actually.
              The rest of the Collection hierarchy would have had to be pretty different from what it is now though. For instance,
              List list = new ArrayList();
              list.add("abc");
              
              Map map = new HashMap();
              map.add("abc"); // What does that even mean here?
              • 4. Re: Map Interface
                843789
                jverd wrote:
                The rest of the Collection hierarchy would have had to be pretty different from what it is now though. For instance,
                The minimal change probably would be to add a Pair type (or Entry as Map calls it) holding an association. Then there could be two overloaded add methods in Collection, one taking a T object and one a Pair<T,S> object. This isn't such a big step considering that add is mandatory even today.
                map.add("abc"); // What does that even mean here?
                It could be equivalent to

                map.add(new Pair("abc",null));
                • 5. Re: Map Interface
                  843789
                  wastrel wrote:
                  jverd wrote:
                  The rest of the Collection hierarchy would have had to be pretty different from what it is now though. For instance,
                  The minimal change probably would be to add a Pair type (or Entry as Map calls it) holding an association. Then there could be two overloaded add methods in Collection, one taking a T object and one a Pair<T,S> object. This isn't such a big step considering that add is mandatory even today.
                  map.add("abc"); // What does that even mean here?
                  It could be equivalent to

                  map.add(new Pair("abc",null));
                  But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural. How would classes implementing java.util.List implement it, for example? The add(Pair) method would be unnaturally implemented in the majority of cases, doing nothing, or throwing UnsupportedOperationException, or however it was implemented.
                  • 6. Re: Map Interface
                    YoungWinston
                    georgemc wrote:
                    But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural.
                    Well, you could have
                    public class Map<K, V> extends Collection<Entry<K, V>>...
                    but in general I agree. Not to mention the fact that Map has a put() method, which is quite different from an add().

                    Winston
                    • 7. Re: Map Interface
                      3004
                      wastrel wrote:
                      jverd wrote:
                      The rest of the Collection hierarchy would have had to be pretty different from what it is now though. For instance,
                      The minimal change probably would be to add a Pair type (or Entry as Map calls it) holding an association.
                      That would be start, but there'd still be much more to change.
                      Then there could be two overloaded add methods in Collection, one taking a T object and one a Pair<T,S> object.
                      No, we're talking about what might've been when the framework was first developed. There were no generics.

                      Collection has an add(Object) method.
                      This isn't such a big step considering that add is mandatory even today.
                      map.add("abc"); // What does that even mean here?
                      It could be equivalent to

                      map.add(new Pair("abc",null));
                      Collection's contracted behavior is when you call add(X), then iterating gives you back X. So map.add("abc") has to give back "abc," but by your equivalence above, it must also give back Pair("abc", null). It can't do both. So clearly this implementation doesn't fit with the definition of Collection.
                      • 8. Re: Map Interface
                        843789
                        YoungWinston wrote:
                        georgemc wrote:
                        But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural.
                        Well, you could have
                        public class Map<K, V> extends Collection<Entry<K, V>>...
                        but in general I agree. Not to mention the fact that Map has a put() method, which is quite different from an add().

                        Winston
                        Erasure means that at runtime, Map would merely be extending Collection.
                        • 9. Re: Map Interface
                          843789
                          georgemc wrote:
                          But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural. How would classes implementing java.util.List implement it, for example? The add(Pair) method would be unnaturally implemented in the majority of cases, doing nothing, or throwing UnsupportedOperationException, or however it was implemented.
                          This approach is quite common. May class libraries have a Pair class for general use or for special use to store associations,

                          [http://dotnetperls.com/keyvaluepair]

                          It's no more unnatural to store an association in a List that in a Set.
                          • 10. Re: Map Interface
                            843789
                            wastrel wrote:
                            georgemc wrote:
                            But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural. How would classes implementing java.util.List implement it, for example? The add(Pair) method would be unnaturally implemented in the majority of cases, doing nothing, or throwing UnsupportedOperationException, or however it was implemented.
                            This approach is quite common. May class libraries have a Pair class for general use or for special use to store associations,

                            [http://dotnetperls.com/keyvaluepair]

                            It's no more unnatural to store an association in a List that in a Set.
                            >
                            >
                            But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural. How would classes implementing java.util.List implement it, for example? The add(Pair) method would be unnaturally implemented in the majority of cases, doing nothing, or throwing UnsupportedOperationException, or however it was implemented.
                            This approach is quite common. May class libraries have a Pair class for general use or for special use to store associations,

                            [http://dotnetperls.com/keyvaluepair]

                            It's no more unnatural to store an association in a List that in a Set.
                            I know. But what you're suggesting, all collections would have a dependency on Pair, regardless of appropriateness, no?
                            • 11. Re: Map Interface
                              3004
                              wastrel wrote:
                              georgemc wrote:
                              But that would mean Collection had a method coupling it to Entry, or whatever we called it, where it wouldn't be natural. How would classes implementing java.util.List implement it, for example? The add(Pair) method would be unnaturally implemented in the majority of cases, doing nothing, or throwing UnsupportedOperationException, or however it was implemented.
                              This approach is quite common. May class libraries have a Pair class for general use or for special use to store associations,

                              [http://dotnetperls.com/keyvaluepair]

                              It's no more unnatural to store an association in a List that in a Set.
                              Common or not, natural or not, it wouldn't work with Collection as it's currently defined.
                              • 12. Re: Map Interface
                                843789
                                jverd wrote:
                                wastrel wrote:
                                Then there could be two overloaded add methods in Collection, one taking a T object and one a Pair<T,S> object.
                                No, we're talking about what might've been when the framework was first developed. There were no generics.
                                Are we? In that case it would've been extremely easy. The 1.2 Collections represented a complete overhaul of the earlier collections and everything was in flux so that would'be been the perfect time to take a different road.
                                Collection's contracted behavior is when you call add(X), then iterating gives you back X. So map.add("abc") has to give back "abc," but by your equivalence above, it must also give back Pair("abc", null). It can't do both. So clearly this implementation doesn't fit with the definition of Collection.
                                This kind of incremental obstacle raising is meaningless. To decide how intrusive or "hard" a library change is one needs to consider a complete proposal.
                                • 13. Re: Map Interface
                                  843789
                                  jverd wrote:
                                  Common or not, natural or not, it wouldn't work with Collection as it's currently defined.
                                  That's not a requirement for this discussion. Besides you claimed in another post that we're not discussing the current Collections. Make up your mind.

                                  A Pair class could've been introduce at any time. It could've been used to put Map under the same umbrellas as the rest of the Collections at any time. The earlier the better of course but even today it would require only minor changes. But one cannot change something without changing it. You're right about that.
                                  • 14. Re: Map Interface
                                    3004
                                    wastrel wrote:
                                    jverd wrote:
                                    wastrel wrote:
                                    Then there could be two overloaded add methods in Collection, one taking a T object and one a Pair<T,S> object.
                                    No, we're talking about what might've been when the framework was first developed. There were no generics.
                                    Are we? In that case it would've been extremely easy. The 1.2 Collections represented a complete overhaul of the earlier collections and everything was in flux so that would'be been the perfect time to take a different road.
                                    Perhaps in the future, you might try reading the thread before responding:
                                    gimbal2
                                    You'll find that it simply isn't possible because maps work on key/value pairs and Collection classes do not.
                                    wastrelA Map could easily have been viewed as a Collection of Pairs.
                                    jverdThe rest of the Collection hierarchy would have had to be pretty different from what it is now though.
                                    Then you went on to propose a trivial change that would not have worked for reasons I explained.

                                    So, as I said: The rest of the Collection hierarchy would have had to be pretty different from what it is now.

                                    Of course it would have been possible to make Map inherit from Collection, but not in a reasonable manner with the current version of Collection.
                                    Collection's contracted behavior is when you call add(X), then iterating gives you back X. So map.add("abc") has to give back "abc," but by your equivalence above, it must also give back Pair("abc", null). It can't do both. So clearly this implementation doesn't fit with the definition of Collection.
                                    This kind of incremental obstacle raising is meaningless.
                                    No, it is not. There's a very simple, fundamental flaw in your plan. It won't work as-is because it cannot fulfill Collection's contract.
                                    To decide how intrusive or "hard" a library change is one needs to consider a complete proposal.
                                    I'm not trying to decide "how intrusive or hard" it is. I'm merely pointing out that Map does not fit in with the current definition of Collection. When you said, "A Map could easily have been viewed as a Collection of Pairs," I took you to mean Collection as it was defined when the framework came out in 1.2. If the Collection you're talking about is a different one, redefined so as to accommodate Map, well, then, duh, of course it's doable. That's a tautology. "Map could easily be a Collection if Collection were defined to accommodate Map."
                                    1 2 3 4 Previous Next