How best to handle dynamically created methods?

Topics: General
May 25, 2013 at 7:15 PM
Ext JS has the built-in ability to automatically generate getter and setter methods for each property defined in a special object named "config". So in normal Ext JS, if a config object defines a key named "userName", the object will automatically have a getUserName() and setUserName() method generated. By default, these return the underlying property value, but they can be overridden to supply additional behavior.

So, obviously one way to do this in TypeScript is to manually define these methods in my class. I'm wondering if there are any other options for this, since it's a nice feature of Ext JS and having to declare all of these methods manually adds a fair bit of unnecessary grunt work. Assuming this makes sense to everyone, are there any other options for dealing with this?


May 29, 2013 at 3:47 PM
Hi Brian,

Right, TypeScript is focused largely on trying to type the non-dynamic members of the object. There may be some way to work around this, if you wanted to use indexers and then have the members share a common type, but there isn't a good way of saying "methods that end with UserName". You could imagine something like this might be possible in the future when used with our overloading rules.
May 29, 2013 at 6:26 PM
Thanks, Jon. This may lead into the more general topic of exposing some sort of compiler directives or interceptors? Seems like it would handle this situation, as well as other possible problems. One example, again with Ext JS, is that Ext JS has its own class system. I'd love to be able to use TS in an IDE, but somehow tell it that I don't actually want it to generate module wrappers, __extends, _super, etc. in the output JS, since Ext JS has it's own way of doing all this internally.

Assuming TS doesn't currently have any way to alter this, would the idea of something like an interceptor (possibly also written in TS) that can modify the output prior to being written out to the JS file be an option? I could see this being useful to handle what are sure are the huge number of unusual/edge cases that can arise when TS rubs up against existing libraries.