Speaking from the "peanut gallery" as just some guy who uses perl a lot...
I agree with the idea of cleaning up the builtin functions so that they're
obvious to the widest possible audience. However, I don't know that what's
"obvious" is that clearcut -- I mostly work on Unix, so I expect "unlin
Ariel Scolnicov:
> It so happens that remove() is standard C (library) for removing a
> file. It therefore makes sense to use *that* name, if any change is
> made.
IMHO, it's poorly named (though using remove() at least has the virtue of
not conflicting with/overloading the existing "delete").
Graham Barr:
> I know other languages call it zip, but personally I dislike that
name
> as zip() is commonly used with reference to compression. Although
> I do not have a good alternative.
Personally, I'd like join() to do this:
@a = (1,3,5) ;
Karl Glazebrook wrote:
> But what is $x[3] ?
> It could be a scalar.
> BUT it could be a reference to a list.
> It could be a reference to a 2D PDL image.
... but references are scalar. So, $x[3] *is* a scalar.
That scalar could be a reference to a list. It could be a reference to a 2D
> > s/x/5/; # this is still going to replace
> > # all the eckses in $_ with fives.
> Why? This is an arbitrary decision if you've declared variables to
be
> barewords.
I think it's a sane decision -- IMHO barewords shouldn't be allowed to
> > And how about:
> >
> > int length = 256 ;
> >
> > and, if that's legal, what does:
> >
> > print "I wonder what this is : " . length ;
> >
> > do?
> I imagine the first order of business for the C JIT team would be
> some conversion operators. Numeric types stringify int
> > same or greater ease than pod for build and configuration.
> >
> > >
> [...]
> > >
> >
> > That is an excellent description of why THIS IS COMPLETE
> > MADNESS.
Maybe I'm reading too much into the comment, but I thought the big deal was
that the example given was not only verbose, but w
