Zoffix Znet via RT wrote: >You can see the returned ObjAt objects are different if you output >their .WHERE addresses:
That kind of comparison distinguishes ObjAt values that *are* meant to be identical: > 3 === 3 True > 3.WHICH.WHERE == 3.WHICH.WHERE False So in both these cases, the 3s and the classes, the ObjAt values are physically distinct but contain the same string. Is there some other way to compare ObjAt values, that shows 3s to be the same but my classes to be distinct? doc/Type/ObjAt.pod says # If two objects compare equally via C<===>, their C<.WHICH> methods return # the same ObjAt object. So in the above case with 3s it implies that these ObjAt objects are considered "the same" even though they're physically distinct. That is, ObjAt identity is functional. >One can argue such ObjAt have to stringify to different values, but >I'm failing to see the need to do so. If I'm wrong, please let me know >and I'll reopen. I believe you're wrong and this needs to be reopened. It appears that the intent of ObjAt is that its physical location is insignificant and that only the value it contains is significant. In that respect it's a functional data structure, like a large Int value. This approach obviously makes sense in order to permit separately-constructed functional objects (such as large Int values) to appear to have the same identity via .WHICH. Furthermore, as far as I can see the string is the entire content of an ObjAt. All the construction expressions are just wrapping up a string. So eq does seem to be the appropriate way to compare ObjAt values. -zefram
