=head1 TITLE
Default methods for objects
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 115
=head1 ABSTRACT
This RFC proposes syntactic support for default methods
that can be defined for blessed references. This would
allow the brackets C<()>, C<{}> and C<[]> to be used
for a variety of convenient syntaxes for objects and
allow abolition of tie's.
=head1 DESCRIPTION
=head2 Motivation
Currently, PDL objects have to use quite an unwieldy syntax
for the all important slicing and indexing. In perl5 the syntax is
$n1 = $n-1; # since we need to stringify
$y = $x->slice("0:$n1:4");
This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:
y = x[0:n-1:4];
In perl we desire to say:
$y = $x[0:$n-1,4];
or even
@y = @x[0:$n-1,4];
If there is a more general unification of PDL arrays and normal
perl arrays. (See L<RFC 116>).
Note that we need to keep l-value subs in perl6 to avoid related
types of syntactical clumsiness if C<$x[]> can invoke a subroutine
(see below).
$x[0:$n-1:4] *= 2;
should be allowed, as well as the long form
$x->slice(0:$n-1:4) *= 2;
Also it is important to be able to do multi-dimensional lookups
efficiently with compact arrays:
$y = $x[1:10,5:99];
L<RFC 117> proposes introducing ranges as part of the
syntax cleanup, this RFC proposes default methods for
objects.
=head2 Default methods
If classes allowed the definition of a default method that
is invoked with a syntax akin to one used with sub refs we
could have the cake and eat it. The default method notion
seems general enough to be useful for other classes. If normal
perl arrays become able to be represented by objects then one might wish
to say C<@x[0:$n-1,4]>
=head2 Examples:
A possible scenario could be as follows. The class PDL
defines a default method that is invoked when a syntax
like
$<variable_name>[args]
is used, where C<$E<lt>variable_nameE<gt>> is supposed to be an
instance of the class in question (here PDL).
The PDL package would contain the definition of the
method C<DEFAULT_SQUARE_STORE> and C<DEFAULT_SQUARE_FETCH>:
package PDL;
....
sub DEFAULT_SQUARE_FETCH {
my $this = shift;
$this->slice(@_);
}
# In this case store/fetch are the same.
*DEFAULT_SQUARE_STORE = \&DEFAULT_SQUARE_STORE;
In a more complex case (for example an array object tied to a
database) the FETCH/STORE methods would be different code.
Similar methods would be provided for C<{}> and C<()>. This
would allow for the creation of a variety of powerful syntaxes
for different kinds of objects. For example in PDL we might
wish to use C<[]> to slice by index value and C<{}> to slice
by physical real-value coordinate.
All this would probably make implementation of tied classes
a lot more straight forward and makes the tieing mechanism
more closely unified with the object mechanism. The current
tie mechanism is unwieldy and inelegant.
One could also think of this as saying C<()>, C<{}> and C<[]>
are operators which can be overloaded.
=head1 IMPLEMENTATION
Changes to the parser to allow the new syntax. Other issues?
Maybe all 3 of these are unnecessary - but at least 2 would
be darn useful.
=head1 REFERENCES
RFC 117: Perl syntax support for ranges
L<PDL> (http://pdl.sourceforge.net/PDLdocs)
http://pdl.perl.org
Numerical Python:
http://starship.python.net/~da/numtut/
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce <belg4mit at MIT dot EDU>
