Is it possible to adjust the class syntax so that the method keyword works with existing codes?

[yuki-kimoto]

Is it possible to adjust the class syntax so that the method keyword works with existing codes?

Examples of existing codes:

  # Point.pm
  package Point;

  sub new {
    ...
  }

  sub move {

  }

  # Many accessors
  sub my_accessor1 {
    # ...
  }
  sub my_accessor2 {
    # ...
  }
  sub my_accessorN {
    # ...
  }

  1;

  # Point3D.pm
  package Point3D;

  use base 'Point';

  # new is inherited from Point in this examle.

  1;

Examples of existing codes with the class syntax:

  # Point.pm
  class Point {

    method new : common {
      ...
    }

    method move {

    }

    # Many accessors
    method my_accessor1 {
      # ...
    }
    method my_accessor2 {
      # ...
    }
    method my_accessorN {
      # ...
    }
  }

  # Point3D.pm
  class Point3D : isa(Point) {
    # new is inherited from Point in this examle.
  }

I'm glad this is OK (OK means this code works well and the redefine warning doesn't occur).

A sample implementation is shown in pseudo code(this is an idea).

  END_OF_CLASS_BLOCK:
    # new is defined in the current class
    if (new_is_defined_in_current_class()) [
      # Do nothing
    }
    # new is not defined in the current class
    else {
      if (new_is_defined_in_super_class) {
        if (super_class_new_is_created_by_corinna) {
          create_corinna_new_in_current_class();
        }
        else {
          # Do nothing
        }
      }
      else {
        create_corinna_new_in_current_class();
      }
    }

Is it possible to adjust the class syntax so that the method keyword works with existing codes?

Benefit

The benefit is that all existing codes use the class syntax and the method syntax with a little fix.

[Ovid]

I would also like to see some of what Corinna provides be available outside of Corinna, but not now. Corinna is already the biggest change to Perl since the release of Perl 5 in 1994. Given the size of the MVP, the PSC made it clear that they would not accept it in its current form due to the risks it presents. Thus, the MMVP was created. While the steering council is aware that some changes may need to be made to address unforeseen issues, expanding the scope of the MMVP (especially for an untested feature) is violating what the council requested.

Sorry for that. Once the MMVP is released (maybe by 38?) and people can start playing around with it for a while, we'll have a better understanding of what our real needs are and we could potentially revisit this issue.