Re: join() and split() to respect string overload operations

[email protected] (Paul LeoNerd Evans)
Newsgroups perl.perl5.porters
Message-ID <[email protected]>
On Mon, Jun 07, 2010 at 01:46:00PM +0200, Abigail wrote:
> I don't consider 'substr' to be the inverse of '.'. In particular, it
> doesn't work the other way around. If substr() is overloadable, then
> 
>     substr $str, $pos, $len, $repl;
> 
> is overloaded as well. How do I reserve that with '.'?

  do { my $new = $str; substr $new, len $str, 0, $repl; $new } 
    eq $str . $repl

> It's not that I oppose 'substr' to be overloadable - I just don't find
> the "reversability" a very compelling argument. There are other overloadable
> operations that aren't reverable: abs, int, bool, "", 0+, qr, x, x=, <>, -X,
> ~~, ${} and friends.

Oh, sure. Some of these operators destroy information and cannot be
inverted.


OK, so lets ignore the mathematical argument of invertable operations,
and go for a much more practical appeal: I would like CORE::substr(),
CORE::split(), and optionally m// and s///, to operate on string-like
objects.

It would be great if

  my $message = String::Tagged->( "Hello, world" );
  $message->apply_tag( 0, 12, b => 1 );

  my $who = ( split ' ', $message )[1];

Would return a String::Tagged object, retaining that tag within it.

Ideally I'd love to be able to, say,

  $message =~ s{(\d+)}
               {String::Tagged->new($1)->apply_tag(0,len $1,fg=>'red'}eg;

To highlight all the numbers in a string in red; but that's largely an
extension exercise.

Simply having CORE::substr() overloadable would be an excellent start on
that.

-- 
Paul "LeoNerd" Evans

[email protected]
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc (application/pgp-signature, 190 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFMDhuzvLS2TC8cBo0RAo3NAJ0fSLnXzDCXxmytn/qXqu2Xz6nVkACeKk9b
1dcIyRT511FyVrHARFKTntE=
=U0rg
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.