Suggestion: Abstract/Opaque types

[jonaskello]

When using a functional programming style it is common to have a module that contains a record type, constructor functions for that record type and other function that operate on that type. For example consider a simple module for a date record:

date.ts

export interface Date { 
    readonly day : number,
    readonly month : number,
    readonly year : number
};

export function createDate(day: number, month: number, year: number): Date {
    return {day, month, year};
}

export function diffDays(date1: Date, date2: Date): number {
 // Imagine implementation that calculates 
 // the difference in days between date1 and date2
}

// Extract the year from the date
export function year(date: Date): number {
    return date.year;
}

This works well to start with. However we may at some point want to refactor the structure of the Date type. Let's say we decide it is better to have it store ticks since epoch:

export interface Date { 
    readonly ticks : number,
};

The problem is now that other modules may have directly read the Date.years property instead of going through our year() function. So other modules are now directly coupled to the type's structure, making our refactoring hard because we need to go through and change all calling modules instead of just changing our date module. (In real-world scenarios the record type is more complex and perhaps nested).

The Ocaml programming language has a nice solution for this called abstract types (see docs here, under the heading "Abstract Types".

The idea is that we export the fact that there is a Date type and you have to use that type to call our functions. However we do not export the structure of the Date type. The structure is only known within our date.ts module.

A suggestion for the syntax could be:

date.ts

export abstract interface Date { 
    readonly day : number,
    readonly month : number,
    readonly year : number
};

other.ts

Import { Date, createDate, year } from "./date"

const date = createDate(2017, 1, 1);
const a = year(date); // OK
const b = date.year; // ERROR

Maybe typescript already has a construct for achieving something similar but my research have not found any.

[jingyu9575]

date.year can be a function call, see Accessors.

export interface Date { 
    readonly day : number,
    readonly month : number,
    readonly year : number
};

class TickDate implements Date {
    constructor(private tick: number) { }

    get day() { return this.tick /* ... */ ; }
    get month() { return this.tick /* ... */ ; }
    get year() { return this.tick /* ... */ ; }
}

const date: Date = new TickDate(1234)

[jonaskello]

Yes that's a good point. class is certainly the right way to achieve encapsulation if you are doing OO style programming. However class is not a good fit for FP style. In FP your building blocks are immutable types (data records) and pure functions. As Javascript is multi-paradigm (OO and FP) I think it would make sense for typescript to support FP style encapsulation too.

Other than the fact that classis a bad fit for FP, there are practical reasons why you would prefer pure data objects over classes. One being that they are easy to serialize to JSON. Another that they are easy to deep compare. Also duck typing works for data objects but not classes. They are also easy to merge etc.

[aluanhaddad]

Just FYI, accessors are also available for object literals

export function createDate(): Date {
  return {
    get year() { ... },
    get month() { ... },
    get day() { ... }
  };
}

I guess my question is, if callers should not have been consuming year, why was it exposed?

[jonaskello]

year is exposed because I need to access it within the module and typescript does not allow any method of hiding it outside the module while still keeping it a plain immutable data record. Hence the feature request :-). For the purpose of FP style, I want to work with only plain immutable data records (types with constructors). There is a good example of how abstract types are used in the Ocaml docs I linked above. They are also mentioned here in a talk about reason which is an Ocaml dialect by facebook with syntax more similar to typescript.

Could you elaborate on how I would use accessors with plain objects? How does the typing look for Date in your example above and what would be the implementation in the { ... } be? Would the accessors not be functions/methods? And would not the accessors be available to other modules, so everyone would know the shape of the Date type?

[aluanhaddad]

@jonaskello that is correct, the accessors would be methods. Such get accessors imply nothing about the structure of the underlying value and can simply return values from the enclosing lexical scope (no need for this).

This does mean that other modules would know the shape of Date but I am not sure how this can be avoided in a structural type system. Well Ocaml is structurally typed...

[jonaskello]

I think you have a good point about not being able to hide the structure in a structural type system. What is needed for abstract types would probably be more akin to nominal typing. However I don't think a full nominal type system is needed just to get abstract types?

I made an example which tries to emulate abstract types. As you can see it breaks down because of structural typing.

EDIT: I managed to update the example so it to some degree emulates nominal typing by using a string literal type as a tag. This may actually be good enough but still it would be nice to have proper support for abstract types.

date.ts

export interface Date {
    readonly type: "ReallySecretDate"
};

interface DateContent {
    readonly day: number,
    readonly month: number,
    readonly year: number
};

type InternalDate = Date & DateContent;

export function createDate(day: number, month: number, year: number): Date {
    const theDate: InternalDate = { type: "ReallySecretDate", day, month, year };
    return theDate;
}

export function diffYears(date1: Date, date2: Date): number {
    const date1_internal = date1 as InternalDate;
    const date2_internal = date2 as InternalDate;
    return date1_internal.year - date2_internal.year;
}

// Extract the year from the date
export function year(date: Date): number {
    const date_internal = date as InternalDate;
    return date_internal.year;
}

consumer.ts

import { createDate, diffYears, year } from "./date";

const date1 = createDate(2017, 1, 1);
const date2 = createDate(2018, 1, 1);

// const year1 = date1.year; // Error - good
const year2 = year(date1); // OK - good
const diff = diffYears(date1, date2); // good

// const year1 = year({}); // Error - good
// const diff2 = diffYears({}, {}); // Error - good

const year1 = year({type: "ReallySecretDate"}); // No Error - not good but maybe good enough
const diff2 = diffYears({type: "ReallySecretDate"}, {type: "ReallySecretDate"}); //  No Error - not good but maybe good enough

[jonaskello]

So I think one conclusion is that two abstract types would need to be considered different even if their structure is the same. This would probably create a simple nominal typing system. So in that sense it may be related to #202.

[jonaskello]

I haven't used Elm myself but it seems to have an abstract type concept, only it is called opaque types. I also think Elm uses structural typing. I just mention it as an example of a language with both structural typing and abstract/opaque types.

[jonaskello]

Calling the types "opaque" may be better than "abstract" since that is an overloaded term already considering abstract classes. Also considering the distinct keyword from this proposal for nominal typing, I would revise my syntax proposal for abstract/opaque types to:

export distinct opaque interface Date { 
    readonly day : number,
    readonly month : number,
    readonly year : number
};

Or perhaps distinct is already implied by opaque and could be left out.

[falsandtru]

class ADate {
    static day(date: ADate) {
        return date.day;
    }
    constructor(
        private readonly day: number
    ) {
    }
}

new ADate(1).day // error
const { day } = ADate;
day(new ADate(1)) // 1

[gcnew]

As @falsandtru said, the trick is to use private.

The following pattern is a good out of the box emulation.

Date.ts

class Date {
    public constructor(
        private readonly day: number,
        private readonly month: number,
        private readonly year: number
    ) {
    }

    // You can make the constructor private and use a static creator
    // function if you prefer it
    static createDate(day: number, month: number, year: number) {
        return new Date(day, month, year);
    }

    static year(date: Date) {
        return date.year;
    }

    static diffYears(date1: Date, date2: Date): number {
        return date1.year - date2.year;
    }
};

export { Date };

export const createDate = Date.createDate;

export const year = Date.year;
export const diffYears = Date.diffYears;

test.ts

import { Date, createDate, year, diffYears } from './Date'

const y2017 = createDate(1, 1, 2017);

// It's ok to use "pojo" Dates as we don't rely on any "methods"
// or hidden class being present
const pojoYear: Date = JSON.parse('{ "year": 2000, "month": 1, "day": 1 }');

y2017.year // error
diffYears(y2017, pojoYear); // 17, as expected
diffYears(y2017, { year: 2000, month: 1, day: 1 }); // error

Note that you don't use classes as OOP classes. You just use the visibility primitives they provide. Such a usage is more of a "namespace" or a module-like dictionary, thus I think it's perfectly inline with the functional style.

[jonaskello]

@falsandtru That's an interesting approach :-). However now we have two levels of encapsulation, the module level and the class level. I think for FP style we want the module to be the only level and not use class at all (I actually ban class with linting rules). Also the module level encapsulation we cannot git rid of so if one has to go it would have to be the class level.

[jonaskello]

@gcnew privatemight be a good idea, if it could be applied without using class, maybe something like this:

export interface Date { 
    private readonly day : number,
    private readonly month : number,
    private readonly year : number
};

[gcnew]

@jonaskello Why does class bother you?