enforce constraints on implemented functions; start by at least checking their signatures

[gabejohnson]

Barring static types, it would be nice to have checks ensuring that if a protocol intends a field to be a method that an implementation at least defines is as a function (preferably of the same length).

protocol A {
  a; // maybe a function
  b(); // definitely a function
  c(d, e); // definitely a function of at least length two
}

class B {
  [A.c](d, e){}
}

B.prototype[A.a] = 'a';
B.prototype[A.b] = 'b';

B implements A; // Error: Symbol(A.b) must be a function

class C {
  [A.b](){}
  [A.c](){}
}

C.prototype[A.a] = 42;

C implements A; // Error: Symbol(A.c) must be a function of length >= 2

[michaelficarra]

Very nice idea! I would love to explore even richer constraints, but this seems like a nice first step.

For now, I will leave this out of the proposal proper until I get a feeling for its support as-is.

[Jamesernator]

Personally I would love some manner of more powerful constraints, although after writing an experimental pattern matching library (here) I found that trying to pattern match functions themselves to be pretty futile and gave up leaving just a generic func pattern which does nothing but check call-ability.

The problem with functions specifically is that there's many valid implementations with different argument lengths thanks to arguments/...args:

function add(a, b) {
    return a + b
}

function add(a, ...[b]) {
    return a + b
}

function add(...[a, b]) {
    return a + b
}

function add() {
    // And we can't forget the old arguments object
    return arguments[0] + arguments[1]
}

So there's no way at class creation time to validate that sort've thing, however you could definitely make it so that it's runtime checked e.g.:

// Supposing some arbitrary fictional syntax
interface Monad {
    bind(Function) -> Monad
}

// Checking on the prototype might be too eager as an instance might still be correct
class Fizz implements Monad {
    constructor() {
        this[Monad.bind] = someInvalidBind
    }
}

class Foo implements Monad {
    [Mond.bind]() {
        return 3
    }
}

class Bar implements Monad {
    [Monad.bind](func) {
        return 'Not a Monad'
    }
}

new Fizz() // InterfaceError, object definitely doesn't satisfy the Monad interface at this point
new Foo().bind(3) // InterfaceError, incorrect arguments for method bind under the Monad interface
new Bar().bind(x => x**2) // InterfaceError returned type doesn't satisfy interface Monad

How feasible this is I'm not certain but it's probably worth looking into, it definitely doesn't enable arbitrary type-checking, but it might allow things to become incrementally "type" checkable.

[gabejohnson]

@Jamesernator I was thinking a simple Function.prototype.length check when implements is invoked. At the very least, it ensures that the number of "required" parameters matches.

[Jamesernator]

Function length is a really really unreliable way of checking things, it breaks with even just a simple decorator for example:

function cached(prop) {
    ...
    // This function has length zero
    return func(...args) {
        ...
    }
}

protocol Foo {
    a(b, c)
}

class Bar implements Foo {
    // @cached a(b, c) has length 0 and so would fail the interface
    // which seems counter-useful
    @cached
    a(b, c) {
        ...
    }
}

That's why I came up with some other syntax so that'd be more towards the goals of what you actually want to validate which is generally protocols themselves.

For example: You care that Monad.bind returns another Monad but you shouldn't really ever care that's its implementation uses ...args or not.

class Future implements Monad {
    [Monad.bind](func) {
        
    }
}

class Future implements Monad {
    // Length 0 but it doesn't matter, it's still a valid implementation
    [Monad.bind](...args) {
        if (args.length === 0 || typeof args[0] !== 'function') {
            throw new Error(`Expected a function`)
        }
        return ...
    }
}

It's very similar to the anti-pattern of checking if a function is an async function, while occasionally useful for introspection it tends to be more common for people to mistakenly use this as a way to try and check if something is synchronous or not, but any function can return a Promise not just async function. Effectively it's the same thing here, the details you care about (whether or not it actually takes two arguments) is separate from the implementation detail of real positional arguments.

I made a small couple functions for experimenting with type-based protocols and it seems to work just fine.

[gabejohnson]

The decorators proposal is Stage 2 AFAIK so I'm not too concerned with interop, but your point is taken @Jamesernator.

[ljharb]

I very much want the ability (totally fine to not do it by default, as in the current proposal) to enforce constraints.

Some use cases include "arraylike", but also define a protocol that describes data records - a "data property descriptor" or "accessor property descriptor" protocol, say.

One suggestion I'd have is augmenting the syntax inside protocol blocks (and a corresponding option name in the dynamic API) that allows an additional "has errors" predicate function to be supplied - the function would return something falsy if there were no errors, and a truthy string if there were any errors - and that string would be used as part of the error message thrown by Protocol.implement et al. That way, if i return nothing, it's valid, but if i return a string, something's wrong.

[LeaVerou]

Declarative richer constraints are definitely not MVP, but I wonder if we could add an imperative way to check constraints, as an escape hatch to make complex things possible, which would buy us a lot of time to figure out how to smoothen the curve between the two.

It could either be for the protocol as a whole, which can check class-wide constraints such as the inheritance chain, or enforce complex constraints such as alternatives:

protocol A {
	implements (Class) {
		// Restrict implementation to specific types
		if (!(Class === Set || Class.prototype instanceof Set) return false;

		// Check if *either* foo or bar is defined
		return Class.foo || Class.bar;
	}
}

Or for specific required members (see #50 for requires syntax):

protocol A {
	requires foo (descriptor) {
		// Additional constraints
		return descriptor.value instanceof Set;
	}
}

or to support future more declarative criteria:

protocol A {
	requires foo {
		checkDescriptor (descriptor) {
			// Additional constraints
			return descriptor.value instanceof Set;
		}
	}
}

Though in the spirit of "what's the minimum we can add to make complex things possible", I'd probably go for just the former.
Note this would also mean implements needs to be added to the list of banned member names (see #57).

Though this would also serve as a workaround for #13, which @michaelficarra said is opposed to. Though perhaps he’s not opposed to other features solving it indirectly?

[michaelficarra]

Hmm, I'm partial to your second option, where each required member can have associated constraint logic, as a function of the descriptor. I don't think the first one is necessary. You can get OR-like behaviour with diamond inheritance patterns, and of course AND-like behaviour is just the default. And I don't see what other class-wide validation you'd do. I certainly wouldn't want someone to do the check that you have in the example that limits who can implement the protocol. That's antithetical to the coordination motivation of the proposal.

But these can always be added as a follow-on. I don't think we need any of this for the initial version of this proposal.

[LeaVerou]

Granular constraints for members totally can (and IMO, should) be added later. The idea for a class-level check was that it's a mechanism to make complex use cases possible, since it is strictly more powerful than all of the options here (at the cost of ergonomics), so it can be used to emulate/polyfill them. It's generally good practice when use cases are not highly concentrated to provide such a low-level escape hatch until better options can be explored for the intermediate levels of abstraction. So while that can also be added later, that would diminish its usefulness in that role.

certainly wouldn't want someone to do the check that you have in the example that limits who can implement the protocol. That's antithetical to the coordination motivation of the proposal.

Some cases truly don't make sense for any and all classes. E.g. in web components, you'd want to restrict protocols to HTMLElement subclasses, or at least Element subclasses if you want to be extra future proof.