in reply to Tie() and substr(), proposal for SUBSTR tie object method

There are several reasons why this proposal wouldn't work, or would be a bad idea.

First, optional tie methods have the habit of breaking inheritance. Consider a hypothetical popular CPAN module that uses a tied SCALAR. Suppose my code creates a subclass of this, where I override FETCH, with something like

sub FETCH { my $self = shift; do_domething; $self->SUPER::FETCH(@_); }
Now suppose that the CPAN maintainer updates his code to include a new FETCHSUBSTR method. I install this version, and suddenly my FETCH method is mysteriously no longer being called.

Second, given the way the perl5 interpreter works, it's not practical to combine array subscripting and substr, so it wouldn't be possible to use *SUBSTR with arrays and hashes.

Lastly, it would help if you explained how the various uses of the substr function were mapped to *FETCH calls, especially when substr is used as an lvalue, eg

$ perl586 -wle 'sub f { $_[0] = "x" } $a = "abcd"; f(substr($a,0,2)); +print $a' xcd

Dave.

Replies are listed 'Best First'.
Re^2: Tie() and substr(), proposal for SUBSTR tie object method
by millueradfa (Initiate) on Jul 11, 2005 at 14:50 UTC
    Sorry for my delay in replying. Yes, since it seems like it would create some problems, perhaps it isnt such a great idea. As far as mapping the *FETCH calls, it probably would have involved FETCHSUBSTR being called for substr($str, $len, $offset), and STORESUBSTR being called for substr($str, $len, $offset, $replacement);. Thank you for everyones replies.