Results matching “smartmatch”

CGI::Tiny & Dispatch::Fu - nearly a perfect match

By Brett Estrade on

CGI::Tiny is a very nice, Perlish way to construct CGI scripts these days. It is perfectly suited as a replacement to CGI.pm and is quite at home in a shared hosting environment.

Here's the example from the POD [1] on metacpan:

    use CGI::Tiny;
    cgi {
      my $cgi = $_;
      # set up error handling on $cgi
      # inspect request data via $cgi
      # set response headers if needed via $cgi
      # render response with $cgi->render or $cgi->render_chunk
    };

I recently coupled this with my new module Dispatch::Fu [2], and it worked exceedingly well. It is a darn pleasure to consider from a distance, if I do say so myself:

 
    use CGI::Tiny;
    use Dispatch::Fu;

    cgi {
      my $cgi = $_;
      dispatch {
        my $cgi = shift;
        if (defined $cgi->param('fribble')) {
          return 'fribble';
        }
        return 'default';
      },
      $cgi,
      on fribble => sub { do_fribble($cgi) },
      on default => sub { do_default($cgi) }; #<~semicolon
    };

    sub fribble {
      my $cgi = shift;
      # application/json;charset=UTF-8
      $cgi->render(json         => { msg => 'fribble says hi' });
    }

    sub default {
      # text/html;charset=$charset
      $cgi = $cgi->render(html  => '<html><head>...');
    }

As you may be able to see, this code is able to scale very nicely as different display needs are added.

Enjoy!

References:

[1] https://metacpan.org/pod/CGI::Tiny

[2] https://metacpan.org/pod/Dispatch::Fu

[3] Syntax highlighting done by converting Perl to HTML at https://tohtml.com/perl/

This article originally appeared at gopher://sdfeu.org/0/users/oodler577/phlogsrc/1694489548.19039.2023-09-12T03%3a32%3a28.txt

Continue reading »

The Hidden Power of Prototypes

By Brett Estrade on

Introduction

I have been leaning very heavily on Perl's prototype feature for creating new modules. The imptetus for this can traced back to the day I looked at the source code for Try::Tiny, and realized that it was implemented using prototypes. The main reason for using prototypes for many new modules I've created recently is my focus on making a thing I do repeatedly available in a more Perlish or idiomatic way.

Required reading if you have not and are about to dive into an article about prototypes: Far More Than Everything You've Ever Wanted to Know about Prototypes in Perl by Tom Christiansen.

The following article demonstrates 2 CPAN modules I have written that focus more on Perl programmer UX and why Perl prototypes can provide a way forward for a great many ideas that people have. Prototypes misunderstood, yes; but more so, they are misunderestimated. They are infact, very powerful and when used for their intended purpose; a lot of hand wringing can be avoided during feature discussions.

Continue reading »

More prototype play: Dispatch::Fu

By Brett Estrade on

I was seeing this so much talk about smartmatch or given/when, I decided to experiment with a prototype powered pseudo structure I'd been thinking about. The results were pleasing to me, and I plan on releasing this soon. I could rename it to match/case (versus fu/on), but the huffman in me likes the short (and semi-ambiguous) "keywords". Let me know what you think in the comments below.

I still need to do more unit tests, POD, dist.ini, etc. But it's the closest I could get what I was observing on P5P. And the current implementation is about as fast and tight as I think it could be. I also enjoy using Perl's datatype coercion capabilities via prototypes* quite a bit. It is a very powerful, underutilized, and misunderstood capability that can be used to bring about a lot more ideas via a "keyword" experience (which is the entire point).

https://github.com/oodler577/p5-Dispatch-Fu

DESCRIPTION

The first block computes a static key based on the contents of $bar. This is user defined, the dev gets a single reference to contain all the goods; they are then unpacked and a static key is computed. It's a form of reduction or digest, or to use a buzz word,classification. The key is then used to do an O(1) dispatch of the handler.

NOTE: it inverts and generalizes the application of the regexps in the "case" statements above. In Dispatch::Fu, a "case" (or on) is a static string; That string is determined in the "match" (or fu), so that's where you'd do the checking with regexps.

The following code works and is very fast. A more involved test from the snippet below can viewed here

SYNOPSIS

use strict;
use warnings;
use Dispatch::Fu;    # exports 'fu' and 'on'

my $bar = [qw/1 2 3 4 5/];

fu {
    # here, give a reference $bar of any kind,
    # you compute a static string that is added
    # via the 'on' keyword; result will be
    # 'bucket' + some number in in 0-5

    my $baz = shift;
    return ( scalar @$baz > 5 )
      ? q{bucket5}
      : sprintf qq{bucket%d}, scalar @$baz;
}
$bar,
  on bucket0 => sub { print qq{bucket 0\n} },
  on bucket1 => sub { print qq{bucket 1\n} },
  on bucket2 => sub { print qq{bucket 2\n} },
  on bucket3 => sub { print qq{bucket 3\n} },
  on bucket4 => sub { print qq{bucket 4\n} },
  on bucket5 => sub { print qq{bucket 5\n} };

Next step is to roll it into a release for CPAN. I will probably change the name, and for now am considering calling it a collapse (into static key) / on. Feedback welcome.

SEE ALSO

* Far More Than Everything You've Ever Wanted to Know about Prototypes in Perl.

Continue reading »

Matching simply

By Toby Inkster on

A little over ten years ago, when Perl 5.18 was approaching its release date, I released match::simple. This was mostly in response to the smartmatch operator (~~) being deprecated, but also a solution to the incredibly arcane rules for how the smartmatch operator operated.

match::simple was intended to be... simpler. The operator looks a little funky because it uses some clever trickery to fake being an infix operator:

    use match::simple;
    
    if ( $this |M| $that ) {
        ...;
    }
Continue reading »

This week in PSC (104) | 2023-04-21

By Perl Steering Council on

All three of us met, having skipped last week.

There wasn’t much to talk about because code freeze ahead of 5.38 is in effect, so there isn’t much going on.

  • We talked further about the upcoming deprecations scheduled for 5.38.0 (smartmatch, tick-as-package-separator), and concluded that we remain committed to keeping them deprecated on the current schedule.

  • Next week’s meeting will be in person in the French city of Lyon.

Continue reading »

This week in PSC (103) | 2023-04-07

By Perl Steering Council on

Paul, Philippe, and Ricardo had our mostly-weekly Zoom call today.

We began by discussing last week, when Pete K from TPRF joined us and we talked about what TPRF could do to help p5p. (Main topics then, which didn’t get any firm action items, were support for critical infrastructure and services and bounties for implementation of PPCs.)

Most of our time this week was spent on the upcoming v5.38.0 release, especially what might be blocking it. (Notable: two new deprecation warnings added in the last two releases — smartmatch, and tick as package separator.)

We discussed strategies used by other languages to make things more attractive for developers, like batteries included. We didn’t end up with any plan of action from this.

In a few weeks, we’ll all be in one place, and look forward to looking carefully at the color of Chartreuse.

Continue reading »

This week in PSC (099) | 2023-03-03

By Perl Steering Council on

After missing last week, all three of us attended.

  • Recapped the missing weeks from absences
  • Smartmatch deprecation seems to be causing some BBC failures due to new warnings, but that’s to be expected; Philippe to submit patches upstream
  • Refined the questions surrounding SSL-in-core; Paul to send a follow-up email
  • RFC0013 needs some core changes to how overload works; best deferred for 5.39 now
  • Agreed to rename “RFC” to “PPC” (“Proposed Perl Change”)
Continue reading »

This week in PSC (096) | 2023-02-03

By Perl Steering Council on

Just Paul and Philippe this week.

  • Smartmatch deprecation continues — just one more distribution left now (Test-Simple).
  • RFC process needs a new name and ID allocation scheme. We will continue discussing ideas and post when we have something presentable.
  • overload::v2 feels like the best solution to the problem of how to add substr overloading.
  • join overloading might want a join_uses_concat flag to avoid surprising existing modules.
Continue reading »

This week in PSC (095) | 2023-01-27

By Perl Steering Council on

A busy meeting today, we talked about quite a few things:

  • Smartmatch deprecation continues. Some upstream PRs have been raised, awaiting CPAN releases
  • Refaliasing might be able to be deëxperimentalized if we add a warning on the currently-failing closure capture cases
  • RFC0013 highlights a deficiency in the overload.pm API shape. Perhaps an opt-in new calling convention is required to make it more flexible. Paul will write another post to the mailing list with more detail
  • Mithaldu’s objection to the suggestion to deprecate map EXPR, LIST suggests that maybe a more powerful debugger “run until next statement” command would be good
  • The interaction of List::Keywords + autovivification highlights the overall problem with highly-pluggable extensible systems - sometimes extensions conflict. We just have to keep this in mind and not have too high expectations that “everything will be fine if we load 20 different plugins”
  • That said, maybe there are some CPAN extensions that ought to be part of the core language - autovivification for example
  • We’ve run out of devel release volunteers now. We need some people to volunteer for 5.37.9, .10, .11, (maybe .12?). Also maybe 5.38.0
Continue reading »

This week in PSC (089) | 2022-12-02

By Perl Steering Council on

Back to the full three of us. Not much needed looking at this week.

  • Posted the smartmatch deprecation message to p5p@; will post it to blogs etc.. after a round of responses.
  • Sent off a reminder that we're looking for help or a project manager on getting SSL support out of the box.
  • Reviewed the RFC tracker and found some that are ready to implement but not nobody has started; they are nearing their expiry time. These are:
    • ${^ENGLISH_NAME} aliases for punctuation variables
    • Optional chaining
    • Drop support for ' as package name separator
Continue reading »
  1 2 3 4 5 6 7  

About coke

user-pic Perl 6 hacker

More info »