Extending lib.d.ts classes like Error is broken when name is aliased about clutz HOT 4 CLOSED

Not sure what to do here yet.
See microsoft/TypeScript#983 which discusses how it's impossible to reference the global-namespaced Error once the namespace contains a class called Error.
Maybe we should take all the built-in (non-namespaced) names and move them to the closure-internal namespace, like

class Error extends ಠ_ಠ.cl2dts_internal.Error {}

but then we need to declare all of those, and in practice the externs/esX.js files should model the same stdlib as the lib.d.ts so maybe we really want this to refer to the Error class from lib.d.ts.

from clutz.

We could just have a map of names that are defined in the global scope, like Error or String etc, and then alias them with some renaming trick (look of approval? Table flip guy?).

from clutz.

Yep, easiest solution would be to add the following

declare namespace ಠ_ಠ.cl2dts_internal {
  type GlobalError = Error;
}

and then just emit GlobalError instead of Error when someone was referencing the global Error. Now the question is whether this should be appended to lib.d.ts or live in its own .d.ts that we have to always pass to TSC.

from clutz.

+1 for modifying whatever "standard lib" typescript receives rather than
another explicit input.
There is a way to do this where we don't modify the existing lib.d.ts, but
instead add a lib.closure.d.ts and make that a standard lib. I've seen
hints about how to do that, so I think we could figure it out.

On Tue, Sep 22, 2015 at 5:21 PM Rado Kirov [email protected] wrote:

Yep, easiest solution would be to add the following

declare namespace ಠ_ಠ.cl2dts_internal {
type GlobalError = Error;
}

and then just emit GlobalError instead of Error when someone was
referencing the global Error. Now the question is whether this should be
appended to lib.d.ts or live in its own .d.ts that we have to always pass
to TSC.

—
Reply to this email directly or view it on GitHub
#81 (comment)
.

from clutz.