3 ms·

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.

by mst 3y ago

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)

jrumbut 3y ago
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.
- uhtred 3y ago
  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.
  - jrumbut 3y ago
    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 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.

by mst 3y ago

jrumbut 3y ago

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.

uhtred 3y ago
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.
- jrumbut 3y ago
  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 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.