in reply to Re: GOLF challenge: destroy dup array elements
in thread GOLF challenge: destroy dup array elements

Nope -- it stringifies everything, which I understand to be contrary to specifications. However, it is inspiring:

sub r{ values%{{map{$_,$_}@_}} }

This preserves references as references -- does that meet the specs?

The Sidhekin

Replies are listed 'Best First'.
Re: Re: Re: GOLF challenge: destroy dup array elements
by blakem (Monsignor) on Sep 06, 2001 at 21:44 UTC
    But wouldn't two items collide in this hash if their stringified representations were the same? For instance, wouldn't an object that stringified to "abc" and the actual string "abc" refuse to coexist in that hash.

    I don't see how using values gets around the stringified nature of the keys.

    -Blake

      Most people are willing to forget about the existence of overloaded objects. The complaint is that keys returns everything in stringified form. So if elements of the hash included anonymous hashes (for instance), you would have a string indicating the hash, but you would no longer have a reference to the hash.

      Using values does not protect you from overload collisions, but it does protect you from returning stringified versions of everything.

        Yes, overload can break this, and yes, I am willing to forget about that. However, my solution treats undef() and "" as the same item, returning only one of them if given both -- which is perhaps not too good ...

        Likewise, if the parameter list contains both a (well-behaved) ref and the stringified version of that ref, my sub will return only one of them. These problems are easily fixed, though the new sub loses some of those golf-like qualities -- it's not quite as neat:

        sub x{ values%{{map{(ref$_?1:defined$_?2:3).$_,$_}@_}} }

        The Sidhekin, wilfully ignoring overload

        OK, got it now... it was solving for a different (and more onerous) problem than I saw. However, the original question did say 'whatever elements' (his bolding, not mine)....., so perhaps a more formal definition of 'unique' and 'whatever' is needed.

        -Blake