From: Dr.Ruud on
John Bokma wrote:

> the arguments
> against using map in void context are more a matter of taste IMO. The
> "its not intended for that" is weak at best, in my (current) opinion.

Recent perls do pretty well with map in a void context.

Unrecent perls have real issues with a map inside a map:
memory allocated by the inner map gets released too late.
Nothing to much worry about, unless the inner map is big.

--
Ruud
From: John Bokma on
"Dr.Ruud" <rvtol+usenet(a)xs4all.nl> writes:

> John Bokma wrote:
>
>> the arguments
>> against using map in void context are more a matter of taste IMO. The
>> "its not intended for that" is weak at best, in my (current) opinion.
>
> Recent perls do pretty well with map in a void context.

which gives me the impression that it's more a matter of taste/style
than using map "wrong" of for something it is not intented for.

But before the flame war really starts, let me repeat that I don't like
it, and it will be unlikely to show up in my code in the near future.

I've done TE for a book in which the author used a lot map in void
context, and each time I remarked "Don't use void in a map
context". While I don't think it's wrong, I wouldn't recommend it to
use it that often in a book. I haven't seen the final version of the
book yet, so no idea what happened with my advice. But it also made me
think: what's really wrong with it. And I couldn't think of a strong
argument other than that it looks odd (to me). And some of the code
looked better (IMO, again style) with for.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
From: J�rgen Exner on
John Bokma <john(a)castleamber.com> wrote:
>"Uri Guttman" <uri(a)StemSystems.com> writes:
>> but in conveying
>> meaning to the reader. map is intended to generate a list, not execute
>> side effects.
>
>But who decides that map is not intended for its side effects? In Perl
>there are IMO quite some constructs that are used in somewhat unexpected
>ways, especially to people new to the language.

The root cause of this confusion is probably that for most people with a
formal background in computer science 'map()' is the first operation
that comes to mind when you want to apply an operation to a list of
values. After all it is one of the three canonical higher-order list
functions map, reduce, and filter.

And because Perl happens to have a function map() that happens to work
the same way in a functional as well as in an imperative programming
style it is only natural that people are using it for both purposes.
And I don't see anything wrong with that.

jue
From: Tad McClellan on
John Bokma <john(a)castleamber.com> wrote:
> "Uri Guttman" <uri(a)StemSystems.com> writes:
>
>>>>>>> "JB" == John Bokma <john(a)castleamber.com> writes:
>>
>> JB> I wouldn't use it though, but like Abigail, IIRC, once wrote, there is
>> JB> no reason to have a problem with map in void context because we use
>> JB> other functions in void context without problems (like print).
>>
>> the point with map in void context is not efficiency
>
> It used to be, and back then, IMO there was a much stronger argument to
> not use map in void context.
>
>> but in conveying
^^^^^^^^^
>> meaning to the reader. map is intended to generate a list, not execute
^^^^^^^^^^^^^^^^^^^^^
>> side effects.
>
> But who decides that map is not intended for its side effects?


That is a red herring.

What is intended by map does not matter, what map conveys to the reader
is what matters.

map conveys "I am building a list" (because it returns a list).


>> for modifier does the same thing and is meant for side
>> effects as it doesn't generate a list. perl has many related things like
>> this and you should choose the one with better semantics for your
>> intentions. map generates lists so use it that way. for modifier doesn't
>> generate lists so use it for side effects.
>
> Like I wrote, I don't like it, and won't use it. But the arguments
> against using map in void context are more a matter of taste IMO.


Using map in a void context is an obfuscation.

Arguments against obfuscation are NOT a matter of taste, they are
a matter of Good Programming Practice.


> The
> "its not intended for that" is weak at best, in my (current) opinion.


That was not Uri's argument.

Uri's argument was that map in void context conveys the wrong meaning.


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
From: Ben Morrow on

Quoth Tad McClellan <tadmc(a)seesig.invalid>:
> John Bokma <john(a)castleamber.com> wrote:
> > "Uri Guttman" <uri(a)StemSystems.com> writes:
> >
> >>>>>>> "JB" == John Bokma <john(a)castleamber.com> writes:
> >>
> >> JB> I wouldn't use it though, but like Abigail, IIRC, once wrote, there is
> >> JB> no reason to have a problem with map in void context because we use
> >> JB> other functions in void context without problems (like print).
> >>
> >> the point with map in void context is not efficiency
> >
> > It used to be, and back then, IMO there was a much stronger argument to
> > not use map in void context.
> >
> >> but in conveying
> ^^^^^^^^^
> >> meaning to the reader. map is intended to generate a list, not execute
> ^^^^^^^^^^^^^^^^^^^^^
> >> side effects.
> >
> > But who decides that map is not intended for its side effects?
>
>
> That is a red herring.
>
> What is intended by map does not matter, what map conveys to the reader
> is what matters.
>
> map conveys "I am building a list" (because it returns a list).

So does delete. Would you object to delete in void context?

Ben

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: LibXML (XPATH) and escape
Next: Module name access