Next: Building Interfaces Around Objects, Up: Interface Interop [Contents]
4.3.1.1 Object Interface Compatibility
It is clear that GNU ease.js’ distinction between two separate interfaces that share the same API is not useful for vanilla ECMAScript objects, because those objects do not have an API for implementing interfaces (and if they did, they wouldn’t be ease.js’ interfaces). Therefore, in order to design a transparently interoperable system, this distinction must be removed (but will be retained within ease.js’ system).
The core purpose of an interface is to declare an expected API, providing preemptive warnings and reducing the risk of runtime error. This is in contrast with duck typing, which favors recovering from errors when (and if) they occur. Since an ECMAScript object cannot implement an ease.js interface (if it did, it’d be using ease.js), the conclusion is that ease.js should fall back to scanning the object to ensure that it is compatible with a given interface.
A vanilla ECMAScript object is compatible with an ease.js interface if it defines all interface members and meets the parameter count requirements of those members.
var Duck = Interface( {
quack: [ 'str' ],
waddle: [],
} );
// false; no quack
Class.isA( Duck, { waddle: function() {} } );
// false; quack requires one parameter
Class.isA( Duck, {
quack: function() {},
waddle: function() {},
} );
// true
Class.isA( Duck, {
quack: function( str ) {},
waddle: function() {},
} );
// true
function ADuck() {};
ADuck.prototype = {
quack: function( str ) {},
waddle: function() {},
};
Class.isA( Duck, ( new ADuck() ) );
Figure 4.5: Vanilla ECMAScript object interface compatibility