[Feature] Implement syntax- and type-support for objects and syntax for user-defined interfaces

[Luna-Klatzer]

Is there an existing proposal for this?

• I have searched the existing issues

This feature does not exist in the latest version

• I am using the latest version

Proposal

Implement TypeScript-like objects and interfaces, which should allow the user definition of objects and the creation of custom Kipper object types (interfaces). These types though should unlike in TypeScript be also available at runtime time in form of an object of type type.

This object should store the relevant metadata of the interface type and be defined once during the creation of the interface.

Interfaces though should primarily be used to define blueprints for objects during compile-time type checking, where each field of an interface must be implemented in an object to meet the interface type criteria e.g. be effectively of that type. These interfaces can then be used as types on variables or arguments as the basic blueprint, where only objects matching the interface can be stored.

For example:

interface Blueprint {
  field: num;
}

// Valid
var obj1: Blueprint = { field: 1; };

// Invalid - Does not meet requirements of interface
var obj2: Blueprint = { };
var obj3: Blueprint = { x: "1"; }

// Invalid - Type 'str' does not meet type 'num' of field 'field'
var obj4: Blueprint = { field: "2"; }

Here though interfaces will not be fully strict and use duck-typing like in TypeScript to check whether an object matches an interface. This means additional fields not specified by the interface can be present in the object, while still correctly matching the type criteria of the interface.

For example:

// Valid
var obj5: Blueprint = { field: 1, anotherField: 2, ... };

Exact behaviour / changes you want

• [Feature] Implement dot notation member-access syntax parent.field #67
• Implement constant object syntax using curly brackets, where an object can be defined with its fields. Same behaviour and syntax with JS object definitions.
• Implement syntax support for interfaces using the interface ... { ... } syntax.
• Implement semantic analysis for the interface, where the following primary issues should be checked:
  • Field definitions are only done once and identifiers may not be duplicated.
  • Field definitions may not overwrite built-in or reserved identifiers.
• Implement type checking for the interface type and variables of that type, where child fields of the type should be properly determined and usable.
• Implement translation of the objects and interfaces in the JS and TS target.
• Implement translation of the runtime interface type (Implementation details in work...)