Roles as Interfaces: What Thoughts on Signatures?

[leonerd]

Among the various "roles" discussions to do with the class system, one use-case I often see is that people want to use them as some sort of "declared interface", in a way similar to the interface keyword in languages like Java and C#. Now, Perl being a dynamic language that doesn't have static typing information; we have duck typing. All of this is entirely optional from an implementation perspective. Perl doesn't need anyone to declare a set of methods that are available on some variable. Given any example that people might write that uses roles purely as interface requirements, you could just delete all the interface declarations and Perl at least would continue to run it just fine. However, I'm aware that much like Perl features like use strict, proper use of declared interfaces like this can help to identify bugs at compile-time, so even while they're not strictly necessary it's still useful to lean into them as a safety mechanism.

With that all in mind, my question today concerns the use of subroutine (well, I suppose we should say "method") signatures on methods in these declared interfaces. In particular: I feel it would be very useful to be able to declare signatures on required method declarations as part of interface-style roles. I definitely think you ought to be able to write the following, for example:

class Shape :abstract {
    method move_to ( $x, $y );
    method resize ( $height, $width );
}

Already to the human reader of this code we've made it more useful than simply declaring a set of method names - we've now been upfront and explained what we expect in terms of argument counts to these methods. At this point it begins to ask questions about how we might compare signatures on this interface declaration against signatures on methods that claim to implement it. Let's now consider:

class Square {
    apply Shape;
    method move_to ( $new_x, $new_y ) { ... }
    method resize ( @args ) { ... }
}

Again to the human reader it feels pretty clear that these two methods satisfy those interface declarations, in that any set of arguments that would satisfy the interface are accepted by these signatures. It doesn't matter that the argument names don't match - that's just internal details of the method body. But we can inspect the argument counts and be happy that all's good. But now what would happen in any of the following situations:

    method move_to ( $new_x ) { ... }    # too few arguments

    method move_to ( $x, $y, $z ) { ... }    # too many arguments

In both of those cases, the actual defined method has a signature that is entirely incompatible with the one given in the interface. It can't possibly work. I feel that this should lead to at least a compile-time warning, if not an outright compile-time error.

But we should note, that the signatures don't have to match exactly. In particular, it's always possiible that an actual method body defined in a class could be more permissive than the interface declaration would suggest. E.g. observe that in the actual Square class above we defined resize to take an entire array of arguments - that could permit zero, one, or more than two values, in addition to the exactly-two that the interface requires. This should be fine.

I'm not sure it's on too many folks' radar yet, but Perl 5.44 will have a new ability in subroutine signatures, of named parameters. While above I said the names of parameter variables aren't important for comparing signatures for compatibility, but we should keep in mind the names of named ones, as they are. So for example, this would be permitted:

# interface declares
    method move_to ( :$x, :$y );

# class provides
    method move_to ( %args ) { ... }    # this is fine

    method move_to ( :$u, :$v ) { ... }    # this is not fine, the names don't match
    method move_to ( :$x ) { ... }    # this is not fine, it doesn't take a 'y'
    method move_to ( :$x, :$y, :$z ) { ... }   # this is not fine, it would require a 'z'

    method move_to ( :$x, :$y, :$z = 0 ) { ... }    # this is fine because the 'z' is optional

These things start to get quite subtle. And I haven't even touched on some of the more exciting questions in this area:

• If an interface declaration provides a default value for a parameter, does the class implementation get to inherit that for free?
• If an interface declaration declares some sort of constraint on argument values (e.g. see the :Checked attribute for subroutine signatures), does the class implementation get to inherit that for free?

In the case of these various "inherit for free" situations, does that come about as a bit surprising? How do we balance Don't Repeat Yourself with the Principle of Least Surprise. It feels surprising if class method implementations suddenly gain default values and argument value validation assertions for free without being declared, but it feels too repetitive if the author of every class method has to write them out again.

I'd like to get at least some vaguely coherent thoughts together on all of these issues before we launch fullscale into trying to implement some sort of "required method interface" ability on the class system, as many of these questions will dig deep into however it gets built.

[karenetheridge]

If an interface declaration provides a default value for a parameter, does the class implementation get to inherit that for free?

Does it even make sense for an interface declaration to declare a default? Maybe that should be left solely to the class.

Otherwise -- let's consider some permutations:

• not including the default could indicate that the author wishes to make the parameter mandatory. But that's adding a constraint to the interface's version of the signature: should that be allowed?
• can the implementation change the default to something else?
• can the implementation add a default to a variable that didn't have a default in the interface declaration?

[dakkar]

I believe Barbara Liskov answered these questions already…

A piece of code that expects an object implementing a certain interface, must work correctly when given any instance from any class that implements that interface.

Therefore:

• a concrete class cannot remove a default: if we have method Interface::wibble($a,$b=5), code can do $obj->wibble(1); if a concrete class says method Concrete::wibble($a,$b) the call will fail. We can't have that (sidenote: Rakudo allows this, but I consider it a mistake, possibly of the implementation)
• a concrete class may change the default, because the set of valid calls to the method doesn't change
• a concrete class may add a default, because the set of valid calls to the concrete class's method is a strict superset of the set of valid calls to the interface's method

none if what I just wrote says anything about usability/affordances, though 😕 I believe that being able to detect these problems at the time the role is applied, would go a long way toward making this usable