issue #6 Code/file templates - class.

[geekdenz]

Basic class templates. Files and cls completion.

[geekdenz]

Just adds some basic code template files and adds them to layer.xml.

Also, there is a template for class.

[Chris2011]

Is this already implemented @jeffrey-easyesi ? I don't think so or?

[Chris2011]

Anything new here?

[geekdenz]

@jeffrey-easyesi & @core developers: I had submitted a pull request ages ago which was not accepted and now there are conflicts. Any reason why it wasn't accepted?

[Chris2011]

Still be not merged?

[Chris2011]

@jeffrey-easyesi @jamie-everlaw are there any problems with the PR? I mean I want to add PRs too, but when they are not merged, that doesn't make sense.

[jeffrey-easyesi]

I rarely create a TS file that contains only one class/enum/interface. It's not like Java where you're pushed towards one top-level class per file.

In contrast with Java, in TS:

• most things cannot be nested inside a class - if you want to define a related class or interface, you must pull it out.
• you can have variables/constants outside of a class
• you can have standalone functions outside of a class. In Java, if you have functions relating to a class that don't operate on an instance, you make them static methods inside the class, even if they don't need access to class internals. In TS you'd more likely pull them out.

As a result, a typical .ts file contains several top level definitions of various kinds.

Moreover, even if you do tend towards putting one definition per file, there are no fewer than 4 different syntaxes you might use depending on how your project is set up:

// global
class C { /*...*/ }

// global inside a namespace
namespace MyProject {
    class C { /*...*/ }
}

// modular, classic style ("import C = require('./C')"
export = class C { /*...*/ }

// modular, ES6 style ("import C from './C'")
export default class C { /*...*/ }

Supporting all of those, with each of class, enum, and interface would require 12 different templates.

I think you can set up your own templates in the Tools > Templates menu if you want. But having templates like these built in the plugin would just clutter up the new-file dialog without adding much value for most users.

[Rycochet]

There's even more than that - I'm really against using default exports 99% of the time, so also needs a version that has them as named exports as well as default export - which immediately doubles the number. Then you've got the single-file projects, with no need for an export as they're simply going to patch into something else (are we triple-slashing, or using import, or using require? How about exporting, is it export or module.exports=)... Even for a single class file that's suddenly gone up to a significant number of choices there... Aaaaand then you add whatever TSLint rules the project relies on, and the template might not even be suitable without changes to begin with.

While the idea for having templates is sound, I don't know that it's any real use to the majority of people.

From a purely technical standpoint this PR has one problem in that the comment at the top is hard-coded, when it should actually use the "proper" NetBeans template copyright system that lets you define it once and get the right comment at the top.