Equality of dbObjects

No, they are never equal and I wouldn't expect them to be equal. If I changed one of those two labels, I would not want the other one to change. When you copied the first, you requested a separate object.

If the variable label1 and the variable label2 referenced the same physical label object, then they would be equal. But by using copy, you requested a second object.

Derek 

SKILL uses eq() for checking identity, and equal() (aka "==") for checking equality.  You're talking about identity, but I want to check that two dbobjects have identical properties/attributes.  If they're eq(), then they definitely will, but if they're not eq(), they could still have equal attributes.  It would be cool if equal() and "==" did something like the forall() code in the OP.

Hi Tom,

But if 'equal()' or '==' changed it would break things all over - Derek is correct, you have two unique db id's that may happen to have the same values for all of the attributes, but any one of these could change and the other label object would remain unaltered.  Your 'forall' test for equality should meet your needs, or some other custom check.  Perhaps a better approach would be to have a SKILL++ method that changed the comparison applied based on the data being passed in, then the same function could be used for all different sorts of data.

Hopefully this helps?

Regards,

Lawrence.

Oh, I see what you guys are saying: the "==" operator calls eq() on dbobjects.  I didn't realize that!  I thought it was just unconditionally returning nil. :) 

"==" on lists does element-by-element comparison, so I'd always assumed dbobjects worked the same way.

I guess it's unlikely two dbObjects would have equal() elements anyway, since they have lots of floating point attributes. Some kind of custom comparison method would be needed, like you suggested Lawrence.

I've always wanted to be able to overload the builtin operators to call my own SKILL++ methods.  Anybody filed a CCR for that yet? :) 

 You can already overload the builtin operators within a SKILL++ lexical scope by defining a function with the same name. For example, see this code example (put in a file with a .ils suffix before loading)

let((a)
 flet(((arrayref (arr ind) arr[ind] || (arr[ind]=makeTable('tab nil))))

  a=makeTable('tab nil)
  a["hello"]["world"]["andrew"]=123
 )
)

defmacro(WithAutoHash (@rest body)
 `flet(((arrayref (arr ind) arr[ind] || (arr[ind]=makeTable('tab nil))))
   ,@body
  )
)

procedure(TrExampleArray()
  let(((arr makeTable('tab nil)))
    WithAutoHash(
      arr["my"]["big"]["test"]=7
      arr["my"]["other"]["test"]=9
      arr
    )
  )
)

This example defines a macro, WithAutoHash, within which it redefines the meaning of arrayref to behave differently - to automatically define an array if an unused index is used. You could do a similar thing with equal (without the macro), using an object oriented approach to define relevant methods (use toplevel('ils) if pasting in the CIW, or a .ils suffix if in a file):

defgeneric(myEqual (obj1 obj2)
  obj1==obj2
)

defmethod(myEqual ((obj1 dbobject) (obj2 dbobject))
  ; do your comparison (return t for now for illustration)
  t
)

; overrride == within the lexical scope defined by the let
let(((equal myEqual))
  printf("Equality test %L\n" dbObj1==dbObj2)
)

Regards,

Andrew

WIthAutoHash: Greatest.  Macro. Ever. 

 Seriously, that's really cool.  :)  

I thought about using let()s to shadow builtin ops like this, but I was afraid to try it in production code.  I assumed nobody ever did crazy stuff like that, so it might reveal bugs in the interpreter  (as happend when I attempted to foldr the and() function over a list and exposed a rare VM bug).  But if a Cadence developer says it's OK, then there's no reason not to start doing it, right? ;)

Thanks a lot!

Thanks ;-)

I'm not a developer (I'm an application engineer), but using this is definitely OK.

The benefit of it being in a lexical scope is that the side effects are completely in your code - you won't be affecting any other users of the built-in operators. It could be rather dangerous to overload existing operators if that affected all callees of that operator/function, because it could break things and be very hard to debug - but since the scope of this is naturally limited, it's perfectly OK.

Andrew.