Partial classes
disshishkov opened this issue · 224 comments
Add support of partial classes. Mixins is not the same, because it's run-time realization. Need compile realization, where partial classes will be combine into one before converting typescript to javascript.
//FileA.ts
partial class ClassA
{
constructor(public name: string) {}
public sayHello(): string { return "hi!"; }
}
//FileB.ts
partial class ClassA
{
public sayBye(): string { return "by!"; }
}will be:
partial class ClassA
{
constructor(public name: string) {}
public sayHello(): string { return "hi!"; }
public sayBye(): string { return "by!"; }
}I think you employ "partial" on modules too and help resolve this issue raised here.
@disshishkov perhaps extension methods be sufficient : #9
What kind of situations do you want to use this for, and how do existing solutions fall short of that?
Note that this was implemented in C# to support WinForms-type editing scenarios where you have an auto-generated file and a user-edited file contributing to the same type; I'm not sure those kind of situations apply in JavaScript/TypeScript.
Some classes can has many line numbers, just for better read splitting to several separate classes will help. You can split by different type, for example by logic (in case where this logic can not moved to another class), by visibility (private and public) and other. In case when combing of partial classes can has problems (for example 2 partial classes same the same method/variable declaration) compiler should notify and throw error.
This isn't really compelling. If your class is so large it can't be comfortably edited in a single file due to its sheer size, it's a very major design smell (e.g. comments in http://programmers.stackexchange.com/questions/157482). Splitting by different type/logic/visibility/etc is something that could be handled by an IDE or by organization within a single file.
It's worth discussing why your classes are so big they can't be navigated (is it because the navigation tools should be better?), and if there are better ways the language could support decomposing a class rather than just splitting it.
Personally, I think "partial classes" should exist, but behave like modules that merge together. I have a system with modules that, although intellisense sees all modules (as it should), the actual JS containing it is only loaded when needed. I think that same would be great for classes as well - to only load the parts needed. I've also wanted to create a function, and use a class to further expand on it. Currently, you can only do this with modules.
A use case for partial classes is for generated proxy classes. E.g. WebAPI or SignalR wrappers. It would be really nice to be able to extend the generated proxy classes with custom logic. Especially when generating classes for models it would be nice to be able to attach business logic directly to the model classes returned from the api.
+1 kvantetore.
The use case is exactly the same as .net; a portion of the class is generated (in our case, from Avro schemas) and you want to add additional helper code for working with the generated classes.
I like this suggestion. I would like to have partial classes in order to separate attributes/properties of classes forming my "data hierarchy" which could be gathered in one single file, from their methods which can be split in several other files. It would make code clearer and easier to understand in one glance imo.
My data hierarchy file:
class A {
x: number;
y: number;
z: number;
}
class B extends A {
value: string;
flag1: boolean;
flag2: boolean;
}File containing methods of class A:
class A {
constructor(x: number, y: number, z: number) {
this.x = x;
this.y = y;
this.z = z;
}
method1(...) { ... }
...
methodN(...) { ... }
}File containing methods of class B:
class B extends A {
constructor(x: number, y: number, z: number, value: string) {
super(x, y, z);
this.value = value;
this.flag1 = false;
this.flag2 = false;
}
method1(...) { ... }
...
methodN(...) { ... }
}+1 from me. I would like to use tt templates to generate Typescript classes, but add to them in a separate file that won't get replaced by the template generation.
+1 This will really help me with my auto generated classes that I need to extend
Partial Class is really nice but it doesn't make sense to have it. It showed you have a design problem. Rule of thumb in programming is to keep it simple stupid (KISS), regardless of languages you use, is to break apart large class into smaller ones - by either 1) splitting off scripts into classes and call them (Other classes can also call that smaller classes too instead of re-inventing the wheel), or 2) break apart & convert into Abstract/Interface/Inheritance/Virtual etc. or polymorphism.
Let's say you have a Vehicle with everything in it. A partial class doesn't make sense and it introduce complexity & overhead here where it makes more sense to do this instead. Create an Engine class, Tranny class, Drivetrain class, Door class & Tire class as seperate classes and move scripts over to them, that when called can still define a Vehicle within the Vehicle class. It reduce lengthy scripts & script complexity. Chance are you will find you have Door scripts here and there which can be simplified by a Door class. Interface/Abstract/Inheritance/Virtual can be use to alter the Door class definition on some scripts in the Vehicle class.
You're also more likely to have less develoment time this way. I once had the ASP.NET C# Blog that use lots of partial classes. I had struggled with it cuz of too many partial classes and you don't know where they are. It is sort of like dealing with GOTO logic in programming. Bad bad!! I was never able to create a patch for the bugfix successfully, nor was I able to customize the script cuz it was too buried in pile of partial classes (so do some renamed wording).
Just saying it as a 1 cent thought from my mind.
@fletchsod-developer: Some situations are properly handled by inheritance, but not all. And some developers may misuse partial classes, but not all. There are some situations where I find partial classes very, very useful, but if you don't like them, you don't have to use them.
@NoelAbrahams, would you be able to acces the definitions from file1 in file but not vice versa? That's ok for me as long as is independent of inclusion order.
I really hope you guys consider partial classes a la C# for TS... for me the only reason is code generation, which is the primary reason behind C#'s partial classes... we are currently doing a lot of TS code generation, and we expect to be doing more and more... currently we have to rely on "//<code" regions in order to preserve our custom code... it's OK i guess but it's not a universal solution to extending code generated classes... but partial classes are... this way tools can all use the same way of providing extension points to code generated classes... please do expect C#/VB to TS code generation to be a common thing just because it's common to use TS for the client and C#/VB for the server, and it's common, whether good or bad, to want to share code between server and client, at least structure... partial classes would help extend generated code... C# examples all over the place, not just winforms, also EF, RIA, etc...
+1 - Could really use this for adding functionality to auto-generated classes; no other elegant solution exists that I can think of or have read about to date...
+1 - Code generated classes. C#/Java objects serialized to client
Need this also for merging of generated classes!
This would be a very useful feature to allow simple merging of generated code with non-generated code.
+1
+1 - We also need it for partially generated classes, would be more elegant than inheritance which emits quite a bit of code that's not needed for this purpose.
+1
Ran into this limitation again - please add this feature! 👍
+1
+1
+1
+1
People randomly +1 this isn't going to move it on.
The use cases so far are:
- I have really big classes that span multiple files. @RyanCavanaugh indicated that it was likely a major design issue with code that complex and not sufficient to warrant the complexity of implementation.
- It like them.
- An other argument seems to be C# has them.
- The other argument is around generated code from other languages.
The second and third use case is not compelling and the fourth, I suspect needs some level of expounding how delivering #9 wouldn't meet a very similar requirement and even Decorators (#2249).
It does look like #9 would accomplish the same thing and be even more general (because you could extend classes other than your own). But it might be reasonable to want class content in two files (perhaps because one is hand written and the other generated by a template), and to say that both files define the essential members of the class with equal importance, and not require that one file "extend" the class define in the other.
It's an almost existential difference, but perhaps important to some people in some situations.
I don't want partial on classes for reasons stated, but on modules it makes sense IMHO.
Partial classes are extremely useful for specializing use-cases. It is not a violation of any OOP pattern but a way to arrange code document, which provides:
- Ability to split the class/type definition in multiple files. For huge code files, it is maintainability++ feature.
- Opportunity for compiler/build-system to make use of conditional linkage at compile-time. Analogy MSBuild, concrete use-case in C#: DBML, designer classes and even more fancy stuff like https://github.com/dotnet/corefx/pull/2045/files.
- Inherent protection, so two (or more) developers don't run into each other during code check-in. Conflict resolution blows! :)
- Let you generate code into the main partial class, then create another partial for custom overloads. Works perfectly!
I believe in separating business logic and data layers into separate classes and I mostly use static methods in these layers. I really don't see how it could be more code and less maintainable.
While extension method is a core language feature influenced by OO patterns and will be processed at compile-time, partial classes deals with document/code-layout to be stitched at pre-compilation stage. Despite the similarities in partial classes, abstract classes and extension methods, there is a clear distinction.
👍 for bringing the harmless "Partial Classes" to TypeScript.
My use case for partial classes is for code generation -- my team needs to be able to auto-generate part of the class in one file and add custom methods and properties by hand in another file. I'm a bit confused why @RyanCavanaugh is "not sure those kind of situations apply in JavaScript/TypeScript", since this use case is unrelated to the language of choice.
Neither decorators nor extension methods solve the code generation problem as elegantly as partial classes, and each has substantial additional complexities.
+1
+1
+1 for code generation purposes.
In the C# environment, the integration of a transpiler of C# classes to TypeScript classes would remove the need to keep two different definitions of classes between the server and client side as the client side, aka TypeScript class, would be automatically generated and the partial class that this issue is requesting would allow customization when needed while still developing in native TypeScript.
+1 for code generation scenarios
+1 extremely helpful for code generation
Why not use inheritance for code generation?
Inheritance is messier and has more overhead.
On Mon, Aug 10, 2015, 10:09 AM Gorgi Kosev notifications@github.com wrote:
Why not use inheritance for code generation?
—
Reply to this email directly or view it on GitHub
#563 (comment)
.
Inheritance creates useless name couplings
Inheritance is less awesome because it:
- Deepens the prototype chain needlessly and slows down instantiation,
although thats not a big deal for most apps, likely everything but games; - For lack of abstract and override either loses some type safety or
introduces the need for some ackward patterns like casting between the two
types; - Is confusing overall as having a base class communicates the idea that
it can be extended by other classes, which is rarely the case with codegen
Not saying typescript HAS to have partial classes to support codegen, only
that partial classes are so much better at it than inheritance or
composition.
@JoshMcCullough Inheritance overhead in JS is minimal, and I don't see how its messier than partial classes: with those you can potentially split a class into 10 files and chase your methods all over the place.
@yahiko00 What kind of "useless name coupling" are we talking about here? Do you refer to the things you'd need to do to get No. 2 below (hardcoding the name of the extended class)?
- There is some overhead, but its quite minimal - only noticeable if you're doing things that translate directly to a couple of machine instructions
- Good point - you don't get the extended class when you have to reference the generated class from other generated classes.
- Those classes are indeed meant to be extended - otherwise you could generate them and be done with it, right?
AFAIK this is not on the ES7+ radar, is it? That might be problematic...
In any case, attaching extra things to the prototype of an existing class is quite trivial in JavaScript and not at all uncommon, so it might be a good idea to have syntax for that...
It's straightforward in TS but the JS behind the scenes would double the
"protoyping" if you were using base classes for all of your generated data
objects. Probably not a serious performance impact unless you have a ton of
data objects, but it still is unnecessary when we know that "partial
classes" are possible.
On Mon, Aug 10, 2015 at 11:03 AM Gorgi Kosev notifications@github.com
wrote:
@JoshMcCullough https://github.com/JoshMcCullough Inheritance overhead
in JS is minimal, and I don't see how its messier than partial classes:
with those you can potentially split a class into 10 files and chase your
methods all over the place.@yahiko00 https://github.com/yahiko00 What kind of "useless name
coupling" are we talking about here? Do you refer to the things you'd need
to do to get No. 2 below (hardcode the name of the extended class)?class MyClass extends GeneratedMyClass { ... }
@hdachev https://github.com/hdachev
There is some overhead, but its quite minimal
https://jsperf.com/prototype-chain-vs-direct-calls - only noticeable
if you're doing things that translate directly to a couple of machine
instructions
2.Good point - you don't get the extended class when you have to
reference the generated class from other generated classes.
3.Those classes are indeed meant to be extended - otherwise you could
generate them and be done with it, right?AFAIK this is not on the ES7+ radar, is it?
In any case, attaching extra things to the prototype of an existing class
is quite trivial in JavaScript and not at all uncommon, so it might be a
good idea to have syntax for that...—
Reply to this email directly or view it on GitHub
#563 (comment)
.
@Davidhanson90 that file has zero classes in it. Did you mean to post this in a different thread?
I'll post onto the correct thread. #447
+1
+1
+100
+1
+1
+1 for code generation.
I have been getting into angularjs and webapi and I want to make a tool that essentially creates automatic JS definitions from my c# objects and services. I want to then be able to extend these classes without having to edit the "scaffolded" JS definitions. I've see that a few other people are requesting this and it seems like we have similar use cases.
+1 for code generation
+1 for code generation, angular has lots of boilerplate code, we're already doing lots of generation of it, but with partial classes we would be able to do much more.
+1 yet again for code generation. Trying to extend classes in another file is messy at best.
@RyanCavanaugh, what is needed to get this out of "+1" mode and moving in a productive direction?
-1 a following syntax is better for mixins: #2919
Not sure why can't we have both partial classes and the mixins; two totally unrelated features.
+1
This would be nice when code is generated, but you don't want to modify it to add things to the generated code.
+1
I have a proposal that should satisfy both of these use cases:
- You want to write methods of your own class in different places.
- You want to add new methods to someone else's class, e.g. a builtin.
For (2), normally you would just use the :: operator to get infix syntax.
But if you want an old class to be part of a new interface, or if you want to dynamically dispatch, you will need to actually modify the prototype.
interface ITimes {
times(n: number): number
}
Array implements ITimes {
times(n: number): number {
return this.length * n
}
}
// The compiler should check that all methods of ITimes and IOther are implemented.
Number implements ITimes, IOther {
times(n: number): number {
return this * n
}
other(): void {}
}
// The old types should typecheck with the new interface.
const x: ITimes = true ? [] : 0
x.times(3)
// The interface list can be empty. This essentially gives you partial classes.
MyClass implements {
anotherMethod(): void {}
}
(In the example I use string method names, but since these are builtin types, using symbols would be better once those can be typechecked.)
An improvement that this has over true partial classes is that the class has a single definition, and other places merely extend it. This means there's a clear place to import the class from and makes translation to JS easier.
👍 I would love to see partial classes too.
What is the status of this feature?
This use case for example :
I have a Math package that define a class Set, with methods Set#add, 'Set#remove'
// math.ts
export partial class Set {
add(){}
remove(){}
}
I have an optional, heavy, Relational package that define classes Relation and Tuple.
This Relational package would also add a Set#product method.
// relational.ts
///<reference path="./../math/tsd.d.ts"/>
partial class Set {
product(){}
}
export class Relation(){}
export class Tuple(){}
Partial classes would allow me to compose classes in a more flexible way. If I don't want to use the heavy relational package, I can still use the basic Set functionality. Other partial classes will only come in and add extra functionality to the class.
I'm scratching my head to do something that will have a nice API without the use of partials in this case.
All I could come with is some repository pattern.
// Without partials
// base
export class Base {
static registerOperation(opName, method){
this.prototype[opName] = method;
}
operation(name, ...args){
return this[name].apply(this, args);
}
}
// math.ts
import {Base} from './base';
class Set extends Base{
// Define the methods here
add(){}
remove(){}
}
// Or here
Set.registerOperation("add", function(...){});
Set.registerOperation("remove", function(...){});
// relational.ts
import {Set} from './../math/math';
Set.registerOperation("product", function(...){});
// app.ts
import {Set} from 'math';
var set = new Set();
set.add // compiler error
set.remove // compiler error
set.product // compiler error
// have to use something like
set.operation("add", args);
// or
(<any>set).add(arg);
+1 I'm using t4 to generate classes and proxies over WebApi. I think auto-generation is using vastly in typescript and when it comes to auto-generation, partial classes is necessary!
It would be great for splitting aspects of the same class especially in React
+1
+1 Code generation and "Just enough separation" in the case of pure reusable data objects with client-specific attributes for like validation that would be neat to have defined on the class but maintained in a separate piece of source code.
+1 for Code generation of partial classes and handcode additional members for these classes in separate files.
+1
+1 I have large base of methods in our js api service, it would be best to split them into files, which makes it easy to understand each method.
api service like fb (facebook) or gq (google analytics), where you are given one global class or object, which you can use through out your development.
+1
This feature would be a big plus for us too.
We developped a middleware where all types of clients can connect to, and communicate with our servers through it.
We generate some of the client code based on what is exposed by the servers.
So far, everything was ok. But now, we'd like to be able to transfer heterogeneous collections of objects (but with a same base class). The objects transfered are part of the code generated based on the server API.
To be able to use the power of inheritance, abstract methods are the key in this case. But our developpers won't add methods to generated code, i presume everyone knows why ;)
As far as i understood (i'm a C# developper), the solution proposed here (#9) would not allow us to do that.
So, partial classes would be perfect for us. We would generate the class as partial, and if developpers need to add logic or methods, they would just have to write an other part wherever they want.
+1
+1 very helpful for code generation
I wonder if module augmentation basically negates the need for this as a specific feature.
If you have a generated class then you should be able to do something like...
import {MyClass} from "./MyClass.generated"
MyClass.prototype.partialMethod1 = function() {
return true;
}
MyClass.prototype.partialMethod2 = function(abc: string) {
this.doSomething(abc);
}
declare module './MyClass.generated' {
interface MyClass {
partialMethod1(): boolean;
partialMethod2(abc: string): void;
}
}@disshishkov That looks like a good way to implement it under the cover, but I'd still like proper first-class support in the language without the need to manually modify prototypes and maintaining that interface.
I agree with Elephant-Vessel. The manually crafted part of the partial class should be as loosly coupled (at design time in TS) as possible form the generated part.
The suggestion by @david-driscoll works for many cases. However, as far as I can tell, prototypes don't have access to internal variables. This limits the usefulness of this approach in code generation contexts where you want to generate the core parts of your classes and then augment them with custom code.
+1
@david-driscoll that looks like an excellent way to desugar this feature. (would need to add the ability to access to private/protected properties). Wonder what would happen with multiple partial class declaration? What would the mutual visibility of those be?
++ 1 Lack of partial is really hurting me when trying to extend my auto generated models..
I think the only thing in scope here is basically what @david-driscoll proposed -- you could declare new methods (which would be put on the prototype) and new non-initialized properties (which have no codegen), but not new initialized properties (because these have side effects on the constructor codegen).
downvoted, pardon my french, partial classes are a stupid attempt to chunk your god classes, which are inevitable in OOP, into multiple files so that they are easier to manage (although still being god classes)
with OOP there is no future for you people (been there, know what i am talking about)
come to FP, we have cookies and a way to write a program without a single class and s**t like this
So we already basically allow this anyway through interface A { method(): void } A.prototype.method = function() { };; codifying this into a sugar for exactly that makes sense.
One thing to bikeshed is the keyword partial. A brief historical vignette: In C#, partial class was originally going to be extension class (which you put on all but one declaration), but there wasn't a clear distinction about which declarations would be the extension and which declaration would be the non-extension declaration. Instead you have the modifier partial that you must place on all classes.
This is not the case in TypeScript; rather the opposite. Here, only one class (let's call it the "primary declaration") may have constructors / initialized member fields; the primary declaration doesn't get any new modifier. Every other declaration (let's call them "extension declarations") may only have statics, methods, and non-initialized fields, and you'll need to have some modifier on them to indicate that they're not primary.
The current best guess is
class Foo {
x = 6; // only legal to initialize here
constructor() { } // only legal to have constructor here
someMethod() { }
}
// vvvvvvvvv thoughts?
extension class Foo {
someOtherMethod() {
}
}✨ 🚲 🏠 ✨
Bikeshedding or not, this is sounding an awful like #311 which was walked away from because of likely interfering with future ECMAScript standards. Why is this worth considering, but proper mixin support isn't?
Using the keyword extension conflicts with extension methods? Or is this going to negate extension methods completely?
@kitsonk I think the mixin proposal has a lot more open questions. The partial class proposal here is just a codification of things that are already allowed in TypeScript, just with some syntactic sugar (this feature could literally be done as a syntactic remapping to things we already have).
@Elephant-Vessel I don't think extension methods are happening if partial classes happen. Classes are the only place where extension methods make sense given our constraints, and the proposed ES7+ bind operator is a better way to shoehorn in extension-like syntax.
@RyanCavanaugh: to me, it seems a bit constraining to require that one class is primary and the others not. If you want to partition your code so that one file contains all the methods of a class and the other contains all the properties, neither seems more obviously primary, and why should you be forced to choose? Isn't it cleaner to have partials where they're all equal in importance, and merged by the compiler?
@RyanCavanaugh ... I would do it exactly the same way c# does it... it works great for code generation... which i believe was the primary problem the feature meant to solve in c#... although my memory is fuzzy... never had any issues, it's been around for years, and is battle tested...
If partial/extended classes won't be able to have initialized fields, I think it would be extra neat to support something like partial methods that we know from C#, basically a lightweight contract specific for partial classes. So like:
public partial class MyGeneratedClass
{
partial void Initialize();
public constructor()
{
//...
this.Initialize();
}
}
public partial class MyGeneratedClass
{
partial void Initialize() { //... }
}
The need to be able to partialize/extend third-party classes could be quite easily(?) solved by making the partial/extends generally optional but required for use of partial methods.
I think that this could bring some neat expressive and operative power to the concept that we want here.
Those who's looking for mixins.
Consider the object initializes proposal by means of which (and flow analysis) the mixins can be done elegantly, naturally, idiomatically right as far as JavaScript goes:
function enableBeingPositioned<a>(
// hypothetical syntax
something: a /* <-- before type */ => a & { x: number; y: number; } /* <-- after type */
): void {
something.x = 0;
something.y = 0;
}
let value = {};
value.x; // <-- should not typecheck
enableBeingPositioned(value);
value.x; // <-- should typecheckLanguages such as Java don't offer partial classes/structs. It is a niche feature of C#. Imitating C# "partial class/struct" concepts to full extent is the best way to go here.
In pre-compilation step, the first thing the TS compiler could do is to stitch the partial code blocks in memory and then move on to the regular compilation pipeline route. This will be more than enough to qualify for v1.0.0-preview1.0000 of Partial Classes feature in TypeScript.
Anything beyond what C# is offering is something that can be introduced in later versions when the feature will evolve and outlive its trial/preview. The corner cases and the similar kind of obscure stuff can be discussed separately one at a time and we can worry about the fit&finish later... IMO.
By the way, as a side note, I imagine many people cringe at the idea of
code generation and are ready to explain to everyone that it has no place
in javascript because there are more idiomatic ways to achieve the same.
There are two ways in which code generation is of great help in some
projects, such as the one I'm working on right now.
- In performance-sensitive projects, such as games, where you just do
everything to max out your cpu budget with useful work, codegen helps a ton
to generate code that is both simple to reason about and highly optimizable
/ monomorphic code that jits really well. For example, in an
entity/component game engine, generated code can help with a ton of stuff
like very fast boilerplate code for sticking components together, event
dispatch, etc. - In big business apps, generated code helps to get extreme mileage out of
the type system, for example by emitting methods with very specific
signatures for database queries, etc, which maxes out compile time
checks, helps a ton with refactoring and also greatly simplifies debugging
because it allows you to step through very simple orchestration code. - The big one is when you're keeping some component in sync across
multiple language environments, e.g. something related to messaging
like protocol buffers, or just json message interfaces, etc.
As another side node for the benefit of anyone wondering what partial
classes have to do with codegen, the value of keeping the generated parts
of a class into a separate file comes from source control requirements -
the generated stuff is usually a rapidly changing build artifact and you
don't want it committed in your repo.
I like the idea of implementing this accordingly to a well known and tried model of this concept, just like what C# has. 'Imitation' has some negative connotations to it, but it has significant value if done intelligently. On the other hand, the 'intelligent'-part of that is to be aware of different circumstances and limitations, so I won't protest if partials for TypeScript does not exactly look like partials for C#.
@Elephant-Vessel, I agree that it needn't be a ditto copy of C# partials, the general design can be laid out first crafted around TypeScript / JavaScript flavor while taking maximum inspiration from C# partials. My suggestion is to go with the 'registering partial keyword' and 'stitching partials' as a first step, and ship it as an experimental/preview feature (so consumer don't start depending on it in production code right off the bat). Later, based on the community response, evolve the feature until it is prod-ready and RTM'd. If we worry about all kinds of tricky gotchas and scenarios before hand, then most probably it will delay the matter further.
+1 - For extending and maintaining generated objects.
+1 for maintaining generated code
I created polyfill and divided my large class.
Define a class as an interface.
export class C {
constructor() {
}
}
export interface C {
m(): void;
}Implement class members.
export default class extends C {
m(): void {
}
}Merge implementations.
import {C} from './core';
import m from './member/m';
compose(C, m);
export {C}import {assign} from './assign';
import {concat} from './concat';
export function compose<T extends new (...args: any[]) => any>(target: T, ...sources: T[]): T {
return concat([target], sources)
.reduce((b, d) => {
void assign(b.prototype, d.prototype);
for (const p in d) if (d.hasOwnProperty(p)) b[p] = d[p];
return b;
});
}I think this is a terrible idea for one specific reason: it will make the already complicated rules for global, ambient, external, namespaced, and brittle declaration order dependent inheritance problems significantly worse. This is not C# and name resolution and member declarations is very different.
Perhaps use an object or namespace instead of a class, a la the revealing module pattern if you really need to do this. Otherwise your class is probably just too large.
Also decorators can be used to implement associations between generated code and hand written code.