Lack of namespacing in types file output can lead to naming collisions

[JessHolle]

It is ... unfortunate that we end up having 2 Xxx names for every given Java class for which we want to access contructors (or enum values). So I get that these don't really fall nicely into a single namespace.

Elevating all "exported" classes to the same global namespace does not seem like an appropriate solution, though.

[bsorrentino]

Hi @JessHolle thanks for valuable feedback.

This project currently is on hold because I've moved on other scripting solution.

If you have still interest in such project and would like help me on its evolution please take in consideration to submit a PR

[JessHolle]

I am considering working on a PR. I am also considering adding TypeScript generation to an existing Javadoc doclet that I have been developing to produce stub Java class sources for a filtered subset of our APIs. I currently output annotations to serve as input to this project, but in that environment I already have the information and developed utilities to understand what to generate. It's just a simple matter of adding code to generate TypeScript stubs in addition to Java ones.

On this issue in particular, I am quite curious if there really is no way to use static methods (and fields) and constructors on TypeScript classes (e.g. with implementation) rather than having to introduce a separate "Static" interface for statics. This leads to a lot of issues as I see it -- and indeed in my case there are numerous naming collisions. I want to avoid those with namespaces and I want to avoid awkward naming tricks as well.

[JessHolle]

After digging into this further I have a bit better understanding of the tradeoffs involved here -- and the impossibility of what I'd really wanted to do.