On Sun, 18 Mar 2007, Uri Guttman wrote: > as for rename on hash keys, why not call it rekey? also even if it is > called rename as a hash method it is different than rename as a function > to rename a file so there is no ambiguity.
The name "rekey" or some such sounds like a reasonable name, and its more descriptive considering the context than "rename" is, since Hash|Mapping element names are called "keys" in Perl. > you can even do: > > @[EMAIL PROTECTED] = delete @[EMAIL PROTECTED]; > > and i am sure a simple p6 thing can be written which takes pairs of > old/new names and loops over them. someone wanna rewrite that here in p6 > and we can see how complex it would be? a rename method might not be so > important then. While you're at it, provide a concise-as-possible example that creates a new Hash container rather than mutating the existing container, because then that example would work with Mapping too. I would consider both mutating and non-mutating versions to be equally useful, but each in different contexts; the non-mutating version is for use by people writing pure functions|expressions and such. But regardless, the system needs to be designed, as an option if not always, such that the operation would fail if any @old_keys don't match a pre-change Hash|Mapping element or if any @new_keys match some other element not being rekeyed. The rationale would be to catch common errors, similar to referencing an undeclared symbol name. Or maybe have separate versions for strict or non-strict behaviour, or a pragma that toggles such, as is appropriate. -- Darren Duncan
