Question On Comparing Objects

[Erik.Friis]

Given the following class:

Code: Select all

:class MyClass
  :field private MyValue

  {del}MyClass x
    :implements constuctor
    :access public

    MyValue<-x
  {del}
:endclass

and the following objects:

Code: Select all

x<-[]new MyClass 5
y<-[]new MyClass 5
xx<-x

My initial expectation was that x{match}y should return a 1, but it returns a zero because the references are different although the value (object) pointed to by the reference is identical. Only x{match}xx returns a 1.

If I define the following variables:

Code: Select all

x<-5 'Hello' (3 3{rho}{iota} 9)
y<-5 'Hello' (3 3{rho}{iota} 9)

x{match}y returns of course a 1, even though x and y point to different arrays in memory. It would seem to me that applying {match} to the actual object as opposed to the pointers to the object would be an order of magnitude more useful and a lot more consistent with the way match has always worked. Even C++ allows for a member by member comparison simply by using = on the references to objects.

Other than writing your own member function in every class or a "weird" function that does an execute on namelist of all fields/vars in the object (yuck!) - is there an easy way to check for the equivalence of two objects?

Thanks for any input!

[Phil Last]

No. But I'm sure someone might let you borrow theirs.

There was a long discussion about this a couple or three years ago which ended up making ≡ entirely redundant (exactly equivalent to =) on refs. I believe the justification has to do with the possibility that the two nss in question might themselves contain further inward or outward pointing refs and the difficulty of deciding whether they too should be equivalent.

Would these be the same

      a←⎕NS'' ⋄ b←⎕NS'' ⋄ (a b).c←a

where one contains a self-ref while the other contains an external ref albeit that they are the same ns? What about

      (a b).c←b a

which now both contain external refs that stand in the same relation to one another but are not the same?

[Erik.Friis]

I think the way that this is going to play out is that Dyalog is going to have to give us the ability to overload primitives to alter their behaviour. This will allow the programmer to alter the behaviour of {match} with object arguments. See my post of the need for copy constructors.

[paulmansour]

After much use, I am very happy and comfortable with the way =, and all the other scalar primitives work on objects and namespaces - looking at the reference.

With regard to how to check for the equality of two instances, I do it with XML. XML is useful, crtical really, for the storage and transfer of objects. Other than simple namespace with vars in it, you really don't want to write an object out to disk, file, or transfer it over the wire - in fact I don't know if you can even do it. Therefore it is very useful that every class in your object model has a ToXML method that returns an XML string, and that you have a ToObject function to turn the XML back into an object. I think all the .NET things have something like this thought it may called Serialize or something like that.

As Phil noted there was a huge discussion about this a while back, and the way to check the equality of two different namespaces is simply in the eye of the beholder. However, with a clean and well defined object model, I think a good case can be made that two objects are equal if their public, writable, properties are equal. These public, writeable properties are exactly the only things that go into the XML representation of the object. So, once you have the XML rep, it is then trivial to test for equality - you are just comparing strings.

Note that if you design your object model before thinking about XML represention, you may have a problem with doing it. There are sublte design issues what will make the XML rep easy, or impossible. Been there and done that!

[ArrayMac]

@eric '∧/{a.⍵ {match} b.⍵}¨a.properties' is... yuck?

[paulmansour]

@eric '∧/{a.⍵ {match} b.⍵}¨a.properties' is... yuck?

I'm not sure its "yuck" but it won't work if some property values are themselves objects, which they inevitably will be.

[Phil Last]

In fact it isn't going to work at all. Or rather it will always "work" if a.properties exists:

      a b←⎕ns¨'' ''
      a=b
0
      a.properties←'this' 'that' 'and' 'the' 'other'
      {∧/a.⍵ ≡b.⍵}a.properties
1

because the list of strings is the same anywhere. What Eric was characterising as "yuck" is the execute each on each list which might be "yuck" but is the only way to do it.

[Phil Last]

... even if you type it in correctly:

      ∧/{a.⍵ ≡ b.⍵}¨a.properties
1

and for the same reason.