typescript Discussions Rss Feed

New Post: SammyJs: module and function impossible to define in 0.9?

basarat — Thu, 23 May 2013 23:57:22 GMT

So the question is how can we declare the following in the new syntax:

declare module "mymodule" {
    export function (): any;   
}

New Post: SammyJs: module and function impossible to define in 0.9?

basarat — Thu, 23 May 2013 23:54:44 GMT

Yup nvivo. However (as you stated at the end) it will not work when using modules and the import clause. i.e. the following is invalid:

declare function "mymodule"();
declare module "mymodule"{
    
}

import x = module("mymodule");
x();

New Post: Initialize Simple Variables on the Prototype

pixel4 — Thu, 23 May 2013 20:38:55 GMT

Dan,

I've read your response multiple times, but it's not making much sense to me.

Sharing between objects is exactly what prototypal inheritance provides. When I have a function on a prototype, say that function is named name(),that function is shared between all instances and instances of derived classes. That's the default for methods/functions, why not the default for initialization of simple variables (string/numbers/booleans)? We don't make all our methods static do we.

So yes, I do want name shared between all my instances. It achieves the same thing as initializing variables in the constructor chain. I'm not looking for static functionality since I want the instances to be able to update those values. If you believe that instances updating those values will update those values for all instances, then you need to read up again on prototypal inheritance.

To be clear, I'm not requesting a declaration attribute, but it may provide a pathway to a compromise. And I'm not recommending that objects and arrays be initialized in the same manner.


// TS
class Foo {
    // initializing variables, all instances for Foo will start in this state
    a:bool = true;
    c:string = "hello world";
    d:number = 321;
    name:string = "bob";
}

// TSC Output
var Foo = (function () {
    function Foo() {
        // initializing variables at instance construct time
        // this code is run for every instance created
        this.a = true;
        this.c = "hello world";
        this.d = 321;
        this.name = "bob";
    }
    return Foo;
})();

// Desired TSC Output
var Foo = (function () {
    function Foo() {}
    // initializing variables on the prototype
    // this code is run once
    Foo.prototype.a = true;
    Foo.prototype.c = "hello world";
    Foo.prototype.d = 321;
    Foo.prototype.name = "bob";
    return Foo;
})();

New Post: Initialize Simple Variables on the Prototype

danquirk — Thu, 23 May 2013 19:57:31 GMT

Putting variable declarations on the prototype vs the instance variable is completely different semantically. As you've noticed, if you want to optimize for memory usage you can do so explicitly if the semantics match what you desire. Consider if your string property c was instead called name. Do you really want the same 'name' property for every instance of Foo? Maybe you do, if so, you need to make that explicit. How would the compiler automatically know which one you meant? The variable declaration attribute you're asking for is essentially what static already is, it defines things shared between all instances of a class rather than those that exist per instance.

New Post: Initialize Simple Variables on the Prototype

danquirk — Thu, 23 May 2013 19:57:31 GMT

New Post: Classes In Wrong Order In Single File with Inheritance and Circular Reference

BSick7 — Thu, 23 May 2013 16:48:44 GMT

I am having a tough time reproducing in a small example. My project consists of a large amount of files. So many that if I use the built-in visual studio build mechanism, the compiler errors out because the command is so long and gets truncated. Instead, I have to spit out the list of files to a file that I can then run tsc on. In doing so, I inevitably get the error above. If I change the ordering the list of files to correctly match dependencies, all is well.

New Post: Initialize Simple Variables on the Prototype

pixel4 — Thu, 23 May 2013 15:40:36 GMT

In order to reduce memory usage and maybe improve initialization time of objects, has there been any discussion about putting simple values (of string/boolean/number) on the prototype of the class?

TS Input

class Foo {
    a:bool = true;
    c:string = "hello world";
    d:number = 321;
}

class Bar extends Foo {}

var a = new Bar();

TSC Output

var __extends = this.__extends || function (d, b) {
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};
var Foo = (function () {
    function Foo() {
        this.a = true;
        this.c = "hello world";
        this.d = 321;
    }
    return Foo;
})();
var Bar = (function (_super) {
    __extends(Bar, _super);
    function Bar() {
        _super.apply(this, arguments);
    }
    return Bar;
})(Foo);
var a = new Bar();

Expected Output

var __extends = this.__extends || function (d, b) {
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};
var Foo = (function () {
    function Foo() {}
    // simple JS types like strings, numbers and booleans on the prototype
    Foo.prototype.a = true;
    Foo.prototype.c = "hello world";
    Foo.prototype.d = 321;
    return Foo;
})();
var Bar = (function (_super) {
    __extends(Bar, _super);
    function Bar() {}
    return Bar;
})(Foo);
var a = new Bar();

If the output from TSC is by design/spec then maybe this can be added via a variable declaration attribute.

I've been implementing this hack but I'm sure I shouldn't be doing this..

Hack


class Foo {

    a:bool;
    c:string;
    d:number;

    static STATIC_CONSTRUCTOR = function(obj) {
        obj.a = true;
        obj.c = "hello world";
        obj.d = 321;
        return true;
    };

    static STATIC_CONSTRUCTOR_INIT = TLXBase.STATIC_CONSTRUCTOR(Foo.prototype);

}

Thank you.

New Post: SammyJs: module and function impossible to define in 0.9?

nvivo — Thu, 23 May 2013 10:23:42 GMT

I did some tests last night and it seems to work, and it even compiles and produces the expected code in . For basarat and schungx, here is what I did:

Get Paul's code and compile with --declaration

Sammy.ts:

function Sammy() { return null; }

module Sammy {
    export class Application {
        constructor() { }
    }
}
--
tsc --declaration Sammy.ts

The declaration generated in Sammy.d.ts for this is:

declare function Sammy();
declare module Sammy {
    class Application {
        constructor();
    }
}

Create a "file.ts" and reference the Sammy.d.ts you just created:

/// <reference path="Sammy.d.ts" />

var a = Sammy();
var b: Sammy.Application;
var c = new Sammy.Application();

Seems to work for both the declaration as for real javascript code. Overloads can be declared as usual.

So Paul/Dan, it seems that if I'm not using modules and the import clause, this should be possible to map today.

New Post: SammyJs: module and function impossible to define in 0.9?

schungx — Thu, 23 May 2013 09:33:05 GMT

Incidentally, just noticed the ID of this discussion -- 444444.

In Chinese, the number 4 is bad luck, since it sounds similar to "death".

Hope this won't affect this extremely important feature...

New Post: SammyJs: module and function impossible to define in 0.9?

schungx — Thu, 23 May 2013 08:45:32 GMT

@basarat's question is also mine. Basically, we need new syntax for these two:

declare module Sammy {
    export class SammyClass {
        constructor();
    }
    export function (): any;
    export function new (): SammyClass;
}

New Post: SammyJs: module and function impossible to define in 0.9?

basarat — Wed, 22 May 2013 23:48:26 GMT

How would one declare such a module with the new syntax. E.g what is the new syntax for the declaration:

declare module Sammy {
    export function (): any;   
}

New Post: SammyJs: module and function impossible to define in 0.9?

paulb — Wed, 22 May 2013 17:28:02 GMT

What you're looking for is the following:

function Sammy() { return null; }

module Sammy {
    export class Application {
        constructor() { }
    }
}



export = Sammy;

But as Dan said, that's currently blocked by a bug on the import side.

New Post: Real world projects written is TypeScript

jpatte — Wed, 22 May 2013 11:35:01 GMT

We launched FeatureMap recently, a new web application for product management.
The client side is written entirely in TypeScript and makes extensive use of Knockout, Backbone and jQuery. I must say I'm very pleased with TypeScript this far. :)

New Post: SammyJs: module and function impossible to define in 0.9?

nvivo — Wed, 22 May 2013 10:26:11 GMT

Hi Dan,

Please correct me if I didn't understand this. Merged declarations would be declaring the same name twice, like this?

export module Sammy {
    interface Application { }
}
export interface SammyStatic { }
declare var Sammy : SammyStatic;

If not, can you give an example on what should it look like in 0.9?

New Post: release-0.9

fdecampredon — Wed, 22 May 2013 09:31:54 GMT

I see a release-0.9 branch :p

So i guess we can hope about the 0.9 release in the next few days ? :p

New Post: Classes In Wrong Order In Single File with Inheritance and Circular Reference

BSick7 — Wed, 22 May 2013 01:59:41 GMT

My example doesn't correctly illustrate the issues I have had. As I took a different approach, let me try to reproduce. Ultimately, I'm seeing cases where the typescript compiler compiles successfully; however, when run in the browser, the javascript engine crashes in the _extends method because _ is undefined in the following code.

var __extends = this.__extends || function (d, b) {
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};

Stay tuned for an example.

New Post: SammyJs: module and function impossible to define in 0.9?

danquirk — Wed, 22 May 2013 00:38:46 GMT

The export assignment feature combined with merged declarations are designed to allow his sort of pattern going forward. It appears there is currently a bug blocking your particular case (we only just put these features in quite recently) but we do intend to support this pattern.

New Post: SammyJs: module and function impossible to define in 0.9?

nvivo — Tue, 21 May 2013 15:18:17 GMT

DefinitelyTyped has a definition for SammyJS that use modules to organize the definition. Sammy itself uses namespace Sammy for its objects, where you have Sammy.Object, Sammy.Application, Sammy.EventContext, etc, so the module mimics the behavior correctly.

Sammy is also a function, and the main way to call it is var app = Sammy(...);.

In 0.8, the definition works fine with the following (simplified) code:

module Sammy {
    export function (): Sammy.Application;
    ...
    export interface Application {
        new ();
        ...
    }
}

This code no longer compiles in 0.9 due to the breaking change "The ‘module’ keyword no longer creates a type", and requires the first function to be named in the module.

The issue is that I cannot find any code that produces the same behavior for this valid javascript code in TS 0.9.

Sammy is both a global function and a module for classes, and this is perfectly valid javascript. The definition should support a way to have all these lines compilling:

var app = Sammy();
var app = new Sammy.Application();
var app : Sammy.Application;

How to map this behavior in the definiton file for 0.9?

New Post: Debugging TypeScript in Visual Studio (assets served with Cassette)

johnny_reilly — Tue, 21 May 2013 05:33:22 GMT

That's a little frustrating. I'm generating the map files and bundling them with Cassette but Visual Studio isn't picking up on it. I have this:

<script src="/cassette.axd/asset/Scripts/Views/Home/Index.js?82d036dfdf39db3e4f486a9402dca05e83af0e03" type="text/javascript"></script>

And behind the scenes Index.js.map and Index.ts can be found too. However, no joy with the TypeScript debugging. This is a shame as the project I'm working on has a heavy reliance on Cassette. Not sure what to do... I could just rely on the JS debugging I suppose.

New Post: Debugging TypeScript in Visual Studio (assets served with Cassette)

jonturner — Mon, 20 May 2013 16:01:22 GMT

The debugging support in TypeScript uses the source map format that a number of JS tools support, including browsers like Chrome as well. The .map file maps from the output .js file back to the original .ts file. If Visual Studio can't access the .map file, it won't be able to successfully debug directly on your original TS files.

By default, a new TypeScript HTML5 project will create a .map file as part of a debug build. If you're using your own project not based on that template, you'll need to enable source map output yourself using the "--sourcemap" commandline option.

I'm not familiar Cassette, though as you describe it may be introducing a layer of abstraction that's not compatible with the VS plugin. It may be worth trying a simpler setup first to see if you can have success with that.