Hacker News new | past | comments | ask | show | jobs | submit login

Context is something you have to learn to be careful with but used judiciously is often quite neat.

Sigils are great once you realise they're conjugation, i.e. $ -> the, @ -> these, % -> the pairs of, hence

  $foo # the value of foo
  $foo{bar} # the bar value of the hash %foo
  @foo{qw(bar baz)} # the bar and baz values of the hash %foo
  %foo(qw(bar baz)} # the bar and baz pairs of the hash %foo
    # i.e. the last one returns (bar => $bar_value, baz => $baz_value)
(and similarly @foo[1,2,3] for 'these values of the array @foo')

I tend to prefer using p3rl.org/IPC::System::Simple and/or p3rl.org/Capture::Tiny and/or p3rl.org/IPC::Run3 over backticks, and p3rl.org/Path::Tiny over File::Spec (or p3rl.org/Mojo::Path if I'm in a Mojo(licious) app).

Note that for scripts where you don't want to deal with dependencies there's p3rl.org/App::FatPacker which will bolt pure perl deps (which all of the above are) onto the front of your script so you can still deploy a single file, p3rl.org/App::plx for managing a self-contained environment and p3rl.org/Object::Remote for when you don't want to need a script on the far side at all, just the ability to ssh to it and run -some- sort of perl binary.

(I've made quite a lot of effort over the years to minimise the number of times I hear the words "but I can't use CPAN" and them actually be true ;)

Plus for bigger stuff p3rl.org/Mojo::IOLoop and/or p3rl.org/IO::Async (the two event systems co-operate fine in a single process) with p3rl.org/Future::AsyncAwait turns out to be really handy.

(I wrote p3rl.org/Parallel::Map as a wrapper around p3rl.org/IO::Async::Function plus the fmap_ functions in p3rl.org/Future::Utils so I can drop fork based limited parallelism into the middle of a script without having to think about the event loop code underlying the implementation)




Where were you when I was learning Perl? That was the best description of context I've ever seen.

Context was one of those subjects where it's a little tricky but the way it was explained to me made it a complete nightmare to understand.


I picked up perl about 18 months ago and I never really found context hard to understand at all. Not trying to boast- just not really sure what people find hard about it.


The first thing is that it's a little like pointers where it's not too hard but there are a lot of explanations of it that create mystification rather than knowledge.

Stuff like this: https://www.perlmonks.org/?node_id=738558

> There is a way for a user-defined function to have its arguments in a scalar context, but that's seldom used, often discouraged, and outside the scope of this tutorial. Most of the time, subs' arguments are in list context.

> Perl's built-ins don't follow this rule at all. Example 10 does not do what's intended.

If that's your first introduction to context you may find it confusing.

From another one I dug up (might have been bot generated, just thought it was funny): Perl has a concept called context. Context means context, and there are the following two contexts.

The second thing, and this may have been more true in the days of yore when I was learning Perl is that there wasn't much consistency in how context was used. Combined with refs, this creates some painful mental overhead when working with multiple libraries in a project. Do I pass credentials as a list, a reference to a list, a specially formatted string, etc? It's not the end of the world but it adds up.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: