rfc:protocol_type_hinting

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
rfc:protocol_type_hinting [2013/06/26 16:21] – Add significant use-cases ircmaxellrfc:protocol_type_hinting [2013/06/26 16:43] – [Standards Based Interface Declarations] ircmaxell
Line 234: Line 234:
  
 It also solves the triangular dependency problem since the sender never needs to explicitly require the dependency. That can be left for an off-line check (or a test), reducing the amount of and need for dependency resolving tools for the purpose of common interfaces... It also solves the triangular dependency problem since the sender never needs to explicitly require the dependency. That can be left for an off-line check (or a test), reducing the amount of and need for dependency resolving tools for the purpose of common interfaces...
 +
 +==== The Place For Current Interfaces ====
 +
 +Why not just get rid of current interfaces and change their behavior to Structural typing (besides the MASSIVE BC break)?
 +
 +In practice there are two reasons (times) that you would use an interface:
 +
 +1. To provide typing information about a domain object (or a value object). This is where the typing actually means something specific to the application.
 +
 +An example would be a User object in an application. You may want to have a UserInterface which the User class implements, because the interface actually implies that the object *belongs* to the domain. It's providing *type* information about the object.
 +
 +2. To provide functionality information about a object. This where the interface really just describes the functionality of the object.
 +
 +An example would be a service which encodes a password. There's no special typing information needed. The interface simply provides a semantic way of identifying the API of the service. So it's not really providing *type*, but more capability.
 +
 +With this new proposal, Type information would still be implemented via traditional interfaces. But capability information would use Structural Typing.
 +
 +So there is very much a place for both to live side-by-side in the same language.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
rfc/protocol_type_hinting.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1