develooper Front page | | Postings from August 2000

115 (v1): Default methods for objects

Thread Previous
Casey R. Tweten
August 24, 2000 09:52
115 (v1): Default methods for objects
Message ID:
=head1 TITLE

Default methods for objects

=head1 VERSION

  Maintainer: pdl-porters team <>
  Date: 16 August 2000
  Version: 1
  Mailing List:
  Number: 115


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.


=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 

=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


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

  package PDL;


        my $this = shift;

  # In this case store/fetch are the same.


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.


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.


RFC 117: Perl syntax support for ranges

L<PDL> (

Numerical Python:

print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'',site=>
''};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>

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About