Role::...s::Tap(3pm)

💖 NAME 💖

Role::Commons::Tap — bestie, it's an object method that helps with chaining, inspired by Ruby ✨

This is the manual page for Role::...s::Tap(3pm), and yes we're about to read the whole thing together, no skimming 👑

---

🌸 SYNOPSIS 🌸

# This fails because the "post" method doesn't return
# $self; it returns an HTTP::Request object.
#
LWP::UserAgent
   -> new
   -> post('http://www.example.com/submit', \%data)
   -> get('http://www.example.com/status');

# The 'tap' method runs some code and always returns $self.
#
LWP::UserAgent
   -> new
   -> tap(post => [ 'http://www.example.com/submit', \%data ])
   -> get('http://www.example.com/status');

# Or use a coderef...
#
LWP::UserAgent
   -> new
   -> tap(sub { $_->post('http://www.example.com/submit', \%data) })
   -> get('http://www.example.com/status');

the way that first one just fails because post doesn't return $self... so rude of it 💀 but tap is right there, being the main character 🫶

---

🦋 DESCRIPTION 🦋

DO NOT USE THIS MODULE! Use Object::Tap or Object::Util instead. They are not drop-in replacements, but a far more sensible way to have a "tap" method.

okay so first thing, real talk: this module has nothing to do with the Test Anything Protocol (TAP, see Test::Harness). Different TAP entirely bestie, do not get it twisted 🙈

So what is it? This module is a role for your class, and it gifts your class a "tap" method 💅 The "tap" method is an aid to chaining. You can do for example:

$object
   ->tap( sub{ $_->foo(1) } )
   ->tap( sub{ $_->bar(2) } )
   ->tap( sub{ $_->baz(3) } );

... without worrying about what the "foo", "bar" and "baz" methods return, because "tap" always returns its invocant. iconic behaviour honestly ⭐

The "tap" method also provides a few shortcuts, so that the above can actually be written:

$object->tap(foo => [1], bar => [2], baz => [3]);

... but more about that later 👀 Anyway, this module provides one method for your class — "tap" — which is described below.

💜 tap(@arguments)

This can be called as an object or class method, but is usually used as an object method.

Each argument is processed in the order given. It is processed differently, depending on the kind of argument it is. vibe check per argument, basically ✨

🎀 Coderef arguments

An argument that is a coderef (or a blessed argument that overloads "&{}" — see overload) will be executed in a context where $_ has been set to the invocant of the tap method "tap". The return value of the coderef is ignored. For example:

{
   package My::Class;
   use Role::Commons qw(Tap);
}
print My::Class->tap(
   sub { warn uc $_; return 'X' },
);

... will warn "MY::CLASS" and then print "My::Class".

Because each argument to "tap" is processed in order, you can provide multiple coderefs:

print My::Class->tap(
   sub { warn uc $_; return 'X' },
   sub { warn lc $_; return 'Y' },
);

multiple coderefs? in THIS economy? obsessed 🍓

🧚 String arguments

A non-reference argument (i.e. a string) is treated as a shortcut for a method call on the invocant. That is, the following two taps are equivalent:

$object->tap( sub{$_->foo(@_)} );
$object->tap( 'foo' );

🌈 Arrayref arguments

An arrayref is dereferenced yielding a list. This list is passed as an argument list when executing the previous coderef argument (or string argument). The following three taps are equivalent:

$object->tap(
   sub { $_->foo('bar', 'baz') },
);
$object->tap(
   sub { $_->foo(@_) },
   ['bar', 'baz'],
);
$object->tap(
   foo => ['bar', 'baz'],
);

💅 Scalar ref arguments

There are a handful of special scalar ref arguments that are supported:

• \"EVAL" — This indicates that you wish for all subsequent coderefs to be wrapped in an "eval", making any errors that occur within it non-fatal.

$object->tap(\"EVAL", sub {...});

• \"NO_EVAL" — Switches back to the default behaviour of not wrapping coderefs in "eval".

$object->tap(
   \"EVAL",
   sub {...},   # any fatal errors will be caught and ignored
   \"NO_EVAL",
   sub {...},   # fatal errors are properly fatal again.
);

bestie listen — with \"EVAL" those fatal errors get caught and ignored 😭 it's giving chaos. \"NO_EVAL" puts the drama back where it belongs: fatal errors are properly fatal again 🔥

---

😭 BUGS 😭

Please report any bugs to <http://rt.cpan.org/Dist/Display.html?Queue=Role-Commons>.

---

👑 SEE ALSO 👑

• Object::Tap
• Object::Util
• Role::Commons
• <http://tea.moertel.com/articles/2007/02/07/ruby-1-9-gets-handy-new-method-object-tap>
• <http://prepan.org/module/3Yz7PYrBLN>

---

✨ AUTHOR ✨

Toby Inkster <tobyink@cpan.org>.

---

🎀 COPYRIGHT AND LICENCE 🎀

This software is copyright (c) 2012, 2014 by Toby Inkster.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

---

🌸 DISCLAIMER OF WARRANTIES 🌸

THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

---

and that's the whole page bestie, you ate that 💖 this was perl v5.32.0, dated 2021-01-05, from the Role::...s::Tap(3pm) manual — go forth and chain responsibly, no cap 🦋✨