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.

[HaraldJoerg]

The title says "adjust the class syntax" - but actually this seems to suggest a change in Corinna behavior?
As far as I understand the proposal, Corinna should "do nothing" if it detects a new method. In that case, the class keyword would be used to define the parent class with :isa(Point) instead of use base 'Point';. And probably the method keyword would just pick of the first element of @_ and provision it as $self, but otherwise behave just like sub?

I doubt this is a good idea. As a start, detection of a new method is a weird indicator to distinguish a Corinna class from existing code. In traditional Perl OO, the name new is a convention, not fixed, so this is not really reliable. It would also permanently block any chance to allow Corinna to add user-defined constructors as suggested by @thoughtstream.

Also, this isn't sufficient:

    if (new_is_defined_in_current_class()) [
      # Do nothing
    }

"Do nothing" in an END_OF_CLASS_BLOCK would at least need to throw a syntax error if any of the Corinna constructs have been used in that class: a :does declaration of a role, a field declaration, one of the phaser blocks. None of these can be made to work with existing code.

I suggest that if authors want to use the keywords class (without roles) and method but not adapt their code to Corinna, then they should implement that as a CPAN module.

[yuki-kimoto]

Thanks.

I doubt this is a good idea. As a start, detection of a new method is a weird indicator to distinguish a Corinna class from existing code. In traditional Perl OO, the name new is a convention, not fixed, so this is not really reliable. It would also permanently block any chance to allow Corinna to add #77 (comment) as suggested by @thoughtstream.

In fact, this adjustment limits Corinna's new method.

I have a feeling that there will be strong opposition and that the discussion will not progress.

I will try another suggestion.

[Ovid]

@HaraldJoerg, @yuki-kimoto I'm trying to find it in the spec (it may have been left out), but in the team's discussions, I seem to recall that it was agreed that defining a new method would be an error. There's so much happening in that method that must happen that if a developer were to do that by hand, they'd probably get it wrong and it would be a constant source of bugs.

new is very special and Corinna must make sure that when new is called, NEWARGS phasers are correctly called (something that the developer can't do because you can't call phasers directly) and ADJUST phasers are called correctly afterwards.

Damian Conway goes into some of the intricacies of construction in this comment. There's simply no way a developer is going to get all of that right, even if they could call phasers.

[yuki-kimoto]

I try another suggestion.

1. Is it possible to add a class attribute that can use the class and method syntax for existing codes using plain old hash reference?

Examples of existing codes with the class syntax:

  # Point.pm
  class Point : plain {
    
    method new : common {
      ...
    }
    
    method move {
      
    }
    
    # Many accessors
    method my_accessor1 {
      # ...
    }
    method my_accessor2 {
      # ...
    }
    method my_accessorN {
      # ...
    }
  }

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

Harald said.

I suggest that if authors want to use the keywords class (without roles) and method but not adapt their code to Corinna, then they should implement that as a CPAN module.

If such a CAPN module is added to core modules, I can understand your proposal from the perspective of fairness.

[Ovid]

1. Is it possible to add a class attribute that can use the class and method syntax for existing codes using plain old hash reference?

I know this is frustrating for you and I'm truly sorry for this, but I don't think we can allow that. The way hashref implementations currently work usually makes it possible to expose state directly and that violates one of the most important reasons for Corinna: encapsulation.

I explain here why encapsulation is so important. And here's a related post of mine explaining this from a different perspective.

I've actually been watching the development of your Class::Plain module and I think when you can get roles and push it a bit further, that's a good compromise between Corinna syntax and hash-based objects. You've got something working, so I would encourage you to push forward on that. I suspect a lot of people might like that compromise.

Eventually, I would like to get Corinna to the point of naturally supporting subtype inheritance instead of behavioral inheritance. To do that, I'm guessing we need to add:

• Proper method signatures (including return types)
• Robust type constraints
• Multimethods (in part because of our anti-pattern of overriding an attribute name to be both a getter and a setter)
• Maybe even DBC (Design by Contract), but I'm less convinced of that.

But all of the above largely goes out the window if we break encapsulation. Encapsulating isn't just hiding state. It's hiding state plus process because those are necessarily intertwined in OO code. The process ensures that the state is always correct. If you expose state without the process, you can no longer ensure correctness. This is true even in strongly-typed languages because the state is often tightly coupled with other bits of state+process, so using one bit of data without the full context of the rest leads to unreliable code. That's why the entire instance is the data type, not just the bits and pieces inside.

[yuki-kimoto]

Thanks. OK. I will try another suggestion.

Ovid and Damian seem to like encapsulation using lexical fields.

[yuki-kimoto]

My first suggestion is related to the new method of the super class.

#93 (comment)

@HaraldJoerg is afraid "The title says "adjust the class syntax" - but actually this seems to suggest a change in Corinna behavior?"

#93 (comment)

And the plain attribute is denied.

I try another suggestion.

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

This is not related to the new method of the super class.

Examples of existing codes:

  # Point.pm
  package Point;

  sub new {
    my $class = shift;
    
    ...
  }
  
  sub move {
    my $self = shift;
  }

  # Many accessors
  sub my_accessor1 {
    my $self = shift;
    # ...
  }
  sub my_accessor2 {
    my $self = shift;
    # ...
  }
  sub my_accessorN {
    my $self = shift;
    # ...
  }
  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 defined in this class
    method new : common {
      my $self = $class->SUPER::new(@_);
      
      ...
    }
  }

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).

It simply doesn't generate a new method if the new method was already defined.

  END_OF_CLASS_BLOCK:
    if (new_is_defined_in_current_class()) [
      # Do nothing
    }

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.