Module references and category methods in .d.ts-es

[PanayotCankov]

Declare the extension methods in the modules where they are declared. Declare /// <reference path="" /> references for dependencies.

For example: objc!Foundation.d.ts

declare class NSString {
    static stringWithString(str: string | NSString): NSString;
}

objc!CoreGraphics.d.ts

/// <reference path="objc!Foundation.d.ts" />
interface CGRect {
}

interface NSString {
    drawInRect(rect: CGRect);
}

The methods still can be used as:

index.d.ts

var nsString = NSString.stringWithString("str");
nsString.drawInRect({});

This will decouple the frameworks a lot, a client app can reference just a small portion of the iOS run-time exposed APIs. Currently Foundation and UIKit have types from CoreGraphics, CoreAudio etc. added thorough categories.

[ivanbuhov]

I understand the pros of your proposal, but just want to hear your opinion on the drawbacks. Separating category methods from the actual class declaration means that if you use a category method from TS you have to know which module it comes from and reference it explicitly. This may be tedious in some cases especially when you are converting native code to TypeScript and you are expecting that all you need to do is copy -> paste -> nativescriptify :). Also, does referencing just a portion of the exposed iOS APIs has any meaningful benefit? I guess it will make the TS compilation step faster, but is it significant enough? Do you see other benefits?

PS: I have no strong opinion on the topic, just trying to understand what is the motivation behind your proposal and see all the pros and cons.

[PanayotCankov]

Users will be able to add all .d.ts-es to their tsconfig.json and their .ts will work as it works now. However they will be able to list just interop, ObjectiveC, Foundation, and UIKit and take use just of the types there speeding up the compilation because there would be no parsing and typechecking for the types in the rest of the 30ish iOS frameworks.

Due to categories I think at the moment Foundation must reference half the iOS framework (see the top references in https://github.com/PanayotCankov/nativescript-big-dts/blob/split/ios/objc!Foundation.d.ts) I will try to provide a working example with performance numbers shortly.

[PanayotCankov]

This is a branch, using the ios-runtime .d.ts generator, that references UIKit and its dependencies. I had to remove some category methods to limit the dependencies and add /// <reference by hand: https://github.com/PanayotCankov/nativescript-big-dts/tree/split

It has a tsconfig references files as:

    "files": [
        "index.ts",
        "lib.core.d.ts",

        "ios/objc!UIKit.d.ts"
    ]

The compilation time is:

nativescript-big-dts cankov$ tsc
Files:              14
Lines:           39779
Nodes:          141338
Identifiers:     55736
Symbols:        252934
Types:           24749
Memory used:   118615K
I/O read:        0.00s
I/O write:       0.00s
Parse time:      0.42s
Bind time:       0.34s
Check time:      2.72s
Emit time:       0.03s
Total time:      3.52s

And this is the same project that builds all .d.ts-es, I just removed the "files" property from the tsconfig.json: https://github.com/PanayotCankov/nativescript-big-dts/tree/split-but-compile-all

mcsofcankov:nativescript-big-dts cankov$ tsc
Files:              90
Lines:          103233
Nodes:          523270
Identifiers:    211010
Symbols:       6740501
Types:           66803
Memory used:   340297K
I/O read:        0.02s
I/O write:       0.00s
Parse time:      1.08s
Bind time:       0.78s
Check time:      5.60s
Emit time:       0.03s
Total time:      7.49s

The index.ts haven't changed even a bit.

[PanayotCankov]

The benefit from categories may not be that big since some of the frameworks forward declare classes from other frameworks :( So there are still quite a lot of dependencies. And UIKit pulls a lot. But adding /// <reference tags will help using portion of the iOS SDK instead of using it all.

[ivanbuhov]

@PanayotCankov Thanks for the valuable info, I am adding this issue to the backlog.