1 2 3 Previous Next 39 Replies Latest reply: Jan 23, 2007 8:19 AM by 807607 Go to original post RSS
      • 30. Re: why don't we  want to define equals() in Comparator interface..........
        807607
        It seems to be from wikipedia's article on marker interfaces:

        http://en.wikipedia.org/wiki/Marker_interface_pattern


        Edit: "It" being a reference to the previous post:

        "I've been googling that boldfaced text, assuming it was a quote from somewhere, but can't find it. Is it just your opinion, boldfaced to make it look more official?"
        • 31. Re: why don't we  want to define equals() in Comparator interface..........
          807607
          It seems to be from wikipedia's article on marker
          interfaces:
          Good catch.

          As a comment on the article, however, the original text (that it indicates "proper" implementation of clone) came from an unattributed edit. So I continue to hold that it's an opinion, not at all supported by the documentation.

          I wasn't there, so take the following with a large grain of salt: I suspect that the original intent for Object.clone() was to support multiple approaches to cloning. If the object implemented Cloneable, that was a signal that a shallow copy was sufficient. Alternatively, it could simply instantiate the object, and rely on the object itself to properly populate its fields.

          As it stands, the Cloneable interface offers very little. The only way around it is to not call super.clone(), which pretty severely limits your options (one alternative is serialization).
          • 32. Re: why don't we  want to define equals() in Comparator interface..........
            807607
            Do you have a reference for this quote? Looking at
            the JDK 1.5 docs, I can't find it in either the doc
            for
            [url=http://java.sun.com/j2se/1.5.0/docs/api/java/lang
            /Cloneable.html]Cloneable, or the doc for
            [url=http://java.sun.com/j2se/1.5.0/docs/api/java/lang
            /Object.html#clone()]Object.clone()

            When did I say I qas quoting from somewhere?

            On the other hand, the Cloneable doc is very
            explicit. I repeat: "A class implements the Cloneable
            interface to indicate to the Object.clone() method
            that it is legal for that method to make a
            field-for-field copy of instances of that class."
            This by no means is even close to what you were saying in your last post!!!

            >
            This is followed in the doc for Object.clone(): "The
            method clone for class Object performs a specific
            cloning operation [...]"
            OK
            In other words Cloneable is a marker interface, used
            only by the implementation of Object.clone(). It's
            not a general indication that the object is
            cloneable.
            Seems you just found out what marker interfaces are!!!


            >
            Edit: I've been googling that boldfaced text,
            assuming it was a quote from somewhere, but can't
            find it. Is it just your opinion, boldfaced to make
            it look more official?
            Though I didnt say I was quoting from somewhere but here you go

            http://en.wikipedia.org/wiki/Marker_interface_pattern

            this might be helpful as well

            http://www.google.com/search?sourceid=navclient-ff&ie=UTF-8&rls=RNFA,RNFA:1970--2,RNFA:en&q=cloneable+marker+interface+indicates
            • 33. Re: why don't we  want to define equals() in Comparator interface..........
              807607
              When did I say I qas quoting from somewhere?
              I assume that, unless you're James Gosling, Josh Block, Neal Gafter, or Doug Lea, any authoritative statement comes from a quote.
              On the other hand, the Cloneable doc is very
              explicit. I repeat: "A class implements the Cloneable
              interface to indicate to the Object.clone() method
              that it is legal for that method to make a
              field-for-field copy of instances of that class."
              This by no means is even close to what you were
              saying in your last post!!!
              It's the same quote, so I'm not sure how it could be different.

              Seems you just found out what marker interfaces are!!!
              Oh nice, an ad hom attack. Without even an attempt to formulate an actual rebuttal. And no, as I indicated in my previous post, that unattributed Wikipedia article is not sufficient.

              If you can find something in the official docs that says Cloneable indicates "proper implementation of clone," I'm willing to believe you.
              • 34. Re: why don't we  want to define equals() in Comparator interface..........
                807607
                well you know what shive you 5 posts up your ass and go do some reading, I dont have time over here to explain to you what marker interfaces are....
                • 35. Re: why don't we  want to define equals() in Comparator interface..........
                  807607
                  Although that's because Cloneable doesn't indicate
                  that an object can be cloned:
                  "A class implements the Cloneable interface to
                  indicate to the Object.clone() method that it is
                  legal for that method to make a field-for-field copy
                  of instances of that class."

                  Ye gods, another post!
                  where the hell did you get the following statement from:-

                  lthough that's because Cloneable doesn't indicate that an object can be cloned:


                  go get some life
                  • 36. Re: why don't we  want to define equals() in Comparator interface..........
                    807607
                    well you know what shive you 5 posts up your ***
                    Hey look, another ad hom attack!
                    where the hell did you get the following statement
                    from:-

                    lthough that's because Cloneable doesn't indicate
                    that an object can be cloned:
                    Which word(s) did you not understand? The docs for Cloneable are very explicit about how Cloneable is used. Nowhere do they say "Cloneable indicates that an object can be cloned."

                    If you can find anywhere in the docs that say "Cloneable indicates that an object can be cloned," or "Cloneable indicates that the object properly implements the clone() method," then I'm happy to listen to you.
                    go get some life
                    Got one, thanks. Enough of one that I don't get my shorts in a twist when someone corrects me.
                    • 37. Re: why don't we  want to define equals() in Comparator interface..........
                      807607
                      well you know what shive you 5 posts up your ***
                      Hey look, another ad hom attack!
                      where the hell did you get the following statement
                      from:-

                      lthough that's because Cloneable doesn't indicate
                      that an object can be cloned:
                      Which word(s) did you not understand? The docs for
                      Cloneable are very explicit about how Cloneable is
                      used. Nowhere do they say "Cloneable indicates that
                      an object can be cloned."
                      the docs say:

                      "A class implements the Cloneable interface to indicate to the Object.clone() method that it is legal for that method to make a field-for-field copy of instances of that class."

                      which means that it indicates that the object can be cloned, not the other way around, what you are claiming.


                      But I guess its useless to have a discussion with you so as far as I am concerned its over and out.
                      • 38. Re: why don't we  want to define equals() in Comparator interface..........
                        807607
                        the docs say:

                        "A class implements the Cloneable interface to
                        indicate to the Object.clone() method that it is
                        legal for that method to make a field-for-field copy
                        of instances of that class."
                        I have highlighted a few key parts in that quote.
                        which means that it indicates that the object can be cloned
                        No, it indicates that Object.clone(), and nothing else, can copy the object in a very specific way.
                        But I guess its useless to have a discussion with you
                        so as far as I am concerned its over and out.
                        Buh bye.
                        • 39. Re: why don't we  want to define equals() in Comparator interface..........
                          791266
                          because java.lang.Object already implements
                          equals(Object) for you
                          and that to me would be even more of a reason
                          not
                          to
                          put the equals method in Comparator interface.
                          Afterall does cloneable interface have clone()
                          method? No!!! then why equals in Comparator.
                          read the rest of the thread! the question was "why
                          don't I have to implement it"
                          yes, and thats where I am coming from if you dont
                          have to implement it, since it is implemented in
                          Object class already and you inherit is it should not
                          be a part of that interface. Just as cloneable
                          The question on why (equals) is included in the interface has already been answered, and I think that it's a very good reason to include the method in the interface - The semantics of the method has changed. Where should you place the javadoc for that change if you don't have a method to place it on?

                          Kaj
                          1 2 3 Previous Next