in reply to Re^2: map question (hash slice)
in thread map question

> Of course, this assumes string values.

Not assuming it is why I went this way. It can also handle an array of refs like this.

Though mixed values may clash.

I started a thread here once where I asked for a solution for this, will dig it out tomorrow.

update

couldn't wait Re: Using hashes for set operations... , but doesn't really help.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Replies are listed 'Best First'.
Re^4: map question (hash slice)
by ikegami (Patriarch) on Jul 29, 2019 at 05:51 UTC

    Except your code assumes strings too. For "objects", you'd need

    my %required; @required{ map key($_), @required } = @required; delete @required{ map key($_), @got }; warn "Skipper is missing: ", values %required;

    Where key is a suitable key-producing sub.

      > For "objects", you'd need

      No not if the array has only refs.

      Collision can only happen if a string looks like a string representation of a ref.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        Maybe. Depends on whether you are checking for identity or equality. If you are checking for identify, then yeah, the key sub could simply return its argument, giving your original code.

        So my comment stands. Your solution is a specific case of my code that only works if one makes multiple assumptions.

      Well, I have the impression a little tweak on the C-sources to add a little magic onto ref-stringification would be enough to implement native set operations.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice