Re^3: A pair of "mathematical" attributes for arrays?

Still I fail to see how could it be "bloat": you would only use it if needed and otherwise happily ignore it or even ignore its existence altogether.

The point of TIMTOWTDI is to offer different sensible ways to achieve the same goal. I fail to see how your proposition offers something that can be generally used. If we were to add every little feature X or Y dream of, Perl would be called PHP.

Except that hinding the thing in a sub would not make the syntax terribly more elegant...

That's just personal taste, but I yet again fail to see how could it not be clearer, since you trade $a[$_] || 0 for a($_). And if you like to think in "mathematical" terms, a sub is much closer to a sequence than an array.

Perl is still useful for fast prototyping, and making the beast unnecessarily slow is what I see as "bloat"

If you're so concerned about speed, you shouldn't use Perl arrays to begin with, since they are very wasteful on space. Either make your own "sequence" data structure in XS or use a module that already exists (maybe PDL ?).

But that's definitely not something everyone would need shipped with his perl.

Comment on Re^3: A pair of "mathematical" attributes for arrays? Select or Download Code

Replies are listed 'Best First'.

Re^4: A pair of "mathematical" attributes for arrays?
by blazar (Canon) on Sep 14, 2007 at 13:32 UTC

The point of TIMTOWTDI is to offer different sensible ways to achieve the same goal. I fail to see how your proposition offers something that can be generally used. If we were to add every little feature X or Y dream of, Perl would be called PHP.

Curiously enough you may think that I am one of those who would like to "add every little feature X or Y dream of", but evidence is that I am not. An example that springs to mind is a recent clpmisc discussion in which someone contended that a trim() function to trim whitespace in front and at the end of a string "should be added in core". For me

s/^\s+//, s/\s+$// for $str;
[download]

is enough.

It is not in contrast with either TMTOWTDI nor with Perl philosophy altogether to add sensible new features especially where current ones are still somewhat lacking and force you to something clumsy and awkward as a workaround.

Comparing my "proposal" with PHP is somewhat of bending the truth, for there's a relevant difference between adding a little bit of unobtrusive semantics and bloating the main namespace with just so many little functions that could be built out of a tiny number of smaller pieces, which is what happens with that language, if I understand correctly.

But that's definitely not something everyone would need shipped with his perl.

Definitely! And I never intended to claim the contrary. It's also definitely something no one should be bothered seeing shipped with her perl. It's something that at least five out of eight partecipants to this thread seemed to receive very positively, while other two didn't express any disliking, simply providing examples of how to get something similar with existing perls. Also, I'm not intending to boast the node reputation, but it indicates that quite a lot of people who didn't followup did like it too.

Anyway, I'm not trying to conVince you. We simply have different views on this particular issue. And anyway we're discussing about something that is most probably not going to be implemented in any case, so we can end it up here.

[reply]
[d/l]
[select]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks