This project is read-only.

No module, an no references

Topics: Language Specification
Jan 29, 2013 at 12:22 PM


I would suggest a drastic change :) No module at all, and no ///reference declaration neither... 

I would personnaly prefer :

1)No ///reference

having to tell the compiler where to find files to compile, eg a config file describing every directories to target (sub-directories will be deduced)... Once done, we don't need to make a ///ref in the code, everything may be find through the config file

2) No module

we don't need modules ; we have classes, and even static declaration for both variables and functions... If you want to modularize, but into stuff classes...

3) Assemblies

it would be valuable to have a "assembly" statement at the beginning of the file where putting the name of a js. library we want to generate. By default, it would be "app".

So we could generate different .js files from a bunch of ts files, eg collection.js, streams.js, http.js and app.js 

best regards


Jan 29, 2013 at 12:38 PM

Sorry, been watching all these "suggestions", and I have to ask: are you serious? Or are you ironically mocking the outlandish and ridiculous feature and change requests that are already in tragic abundance on these boards?

Jan 29, 2013 at 1:02 PM
Edited Jan 29, 2013 at 1:12 PM

ironically serious ;)

Indeed, the way of how the modularization is done and the way it  conflicts with AMD  in the same time is not convincing and also verbose... Discussions in the maling list on the fact to put or not every refs into a file instead of making references into each files, is symptomatic of the fact that the way of modularizing is not stable enough... so why not simplifying everything first before complexifying after?

Jan 29, 2013 at 6:16 PM

I agree that modules are one of the most complex parts of TypeScript.  I'd love to simplify them...

But in hashing them out, much of that complexity is that TypeScript is for creating JavaScript projects and working with the array of JavaScript techniques out there.  We're pretty serious about allowing you to do what you'd do in JavaScript, and JavaScript doesn't have a prescribed way for doing external and internal modules (at least not yet).  Instead, there are multiple acceptable choices people can make for modules, module loading, etc.