That's interesting - I've never used the tie interface before - I remember reading years ago that it is slow, and so just avoided it. Also, I thought that, because the variable is blessed into a package, it would still return it's class name when queried by ref. But you're right, it doesn't.

It is slower, especially tie'ing vs bless'ing, but FETCH'ing vs overload'ed stringification is only about 15% different:

    #==============================
    package i18n::String;
    #==============================

    use strict; use warnings;
    no warnings 'once';
    
    use overload q{""} =>
        sub { $i18n::Current_Lang->maketext( ${ $_[0] } ) };

    sub new {
        my $class  = shift;
        my $string = shift;
        return bless( \$string, $class );
    }

    #==============================
    package i18n::String2;
    #==============================

    use strict;
    use warnings FATAL => 'all', NONFATAL => 'redefine';

    sub TIESCALAR {
        my $class  = shift;
        my $string = shift;
        return bless( \$string, $class );
    }

    sub FETCH {
     $i18n::Current_Lang->maketext( ${ $_[0] } )
    }

    # BENCHMARK INIT ##############
    use Benchmark qw(cmpthese);

    cmpthese(1000000, {
        bless_string => sub { my $s = Burro::i18n::String->new('Januar
+y'); },
        tie_string =>   sub {tie my $s,Burro::i18n::String2,'January'}
    });
    
                     Rate   tie_string bless_string
    tie_string   395257/s           --         -30%
    bless_string 561798/s          42%           --

    # BENCHMARK FETCH  ###########
     use Benchmark qw(cmpthese);
     
     my $s = i18n::String->new('January');
     tie my $n,i18n::String2,'January';
     
     cmpthese(1000000, {
         fetch_blessed => sub {"$s"  },
         fetch_tied    => sub {"$n"}
     });
     
     
                      Rate    fetch_tied fetch_blessed
    fetch_tied    168634/s            --          -11%
    fetch_blessed 190476/s           13%            --
[download]

That said, as far as I can see, tie works only on named variables:

   my @months = map { tie my $var, i18n::String2, $_ } qw(January Febr
+uary);
   print Dumper(\@months);

   $VAR1 = [
             bless( do{\(my $o = 'January')}, 'i18n::String2' ),
             bless( do{\(my $o = 'February')}, 'i18n::String2' )
           ];
[download]

So in the process of solving one issue, I could be introducing many more.

Defensive programming it is!

thanks for the suggestion BrowserUK

Clint

That said, as far as I can see, tie works only on named variables:

So in the process of solving one issue, I could be introducing many more.

Um. The problem is that your map is returning the return value from tie, instead of the tied variable.

If you change the map so:

   my @months = map{tie my $var, i18n::String2, $_; $var } qw(January 
+February);
[download]

That problem goes away also. (I made a similar error myself earlier:)

Provided that your _(...) sub does the right thing, your users need never be aware that they are dealing with anything other than simple scalars.

So, trade your (one-time, up-front) care (and a little getting up to speed with the ins and outs of tie), as you develop your solution, for ongoing and continuous care by all your programmers?

Your choice, but I know which way I would go :)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

If you change the map so:

     my @months = map{tie my $var, i18n::String2, $_; $var } qw(Januar
+y February);
[download]

That problem goes away also. (I made a similar error myself earlier:)

Actually, it doesn't :) What is stored in @months is not tie'd anonymous variables, but the result of FETCH'ing $var. In other words, it does the translation at compile time, rather than at runtime.

Clint