On Tue, Feb 01, 2000 at 01:31:59AM -0500, Ronald J Kimball wrote: > On Mon, Jan 31, 2000 at 11:40:11PM -0500, Andrew Pimlott wrote: > > On Mon, Jan 31, 2000 at 11:01:16PM -0500, Jeff Pinyan wrote: > > > You can get this kind of override by doing this (although it's damn slow): > > > > > > %hash = (%values_get_overridden, %hash); > > > %hash = (%hash, %values_override_hash); > > > > Of course, but if those %'s were @'s, you'd say, "No, silly! That's > > what unshift and push are for!". I want to be able to say the same > > thing for hashes. > > And if those were @'s, then the data structures would be inherently > ordered, contiguous, and indexed numerically. ^^^^^^^^^^ Watch it--that's what the delete on arrays debate is about. As for ordered, well the list from which a hash is initialized is ordered, which isn't far off. And I doubt anyone's declared that hash keys can't be ordered in the future. As for indexed numerically, so what? Pushing and unshifting are commonly done on linked lists, which aren't indexed numerically. > > You may be able to optimize your examples under the hood, but I would > > find this optimization highly unintuitive. Is there currently any list > > context in which arrays or hashes are magically not expanded? Duh--there's an obvious one that's similar: for (1..100000). But is for (@foo) optimized not to copy @foo? I think not because if @foo changes in the loop, the behavior will be wrong. > It does not matter whether the optimization is intuitive or not. Sure it does. An optimization is a lot more valuable if it is commonly triggered by typical code. So, we would like the optimized construct to be idiomatic. %h = %h, %new seems an awkward idiom to me, because my perl intuition tells me it's slow. But maybe I'm just not used to it. Andrew > > PS. I support delete and exists on arrays ;) > > P.S. I support file test operators on regular expressions. P.S. Ew! ==== Want to unsubscribe from Fun With Perl? Well, if you insist... ==== Send email to <fwp-request@technofile.org> with message _body_ ==== unsubscribe