Sorry it didn't seem to update me when you were commenting - apologize for not answering back.

Let me test out passing the class to the metadata registration method and report back.

We've toyed around with compiling (?) an ES6 class so you can use something like this and have it transformed in to metadata -

```
class Person {
@int32 id;
@string firstName;
@string lastName;
}
```

which would be equivalent (and possibly easier to write by hand) than the current metadata -

```
metadataStore.addEntityType({
shortName: "Person",
dataProperties: {
id: { dataType: "Int32", isPartOfKey: true },
firstName: { dataType: "String" },
lastName: { dataType: "String" }
}
});
```

Adding the methods to the class could map to the current Breeze.js constructor method. Just some thoughts :)

UPDATE: I'm informed that you can pass the entity class directly to the breeze metadata registration method today. In what ways is that inadequate? What do we have to change to satisfy your user voice request?

UPDATE: I'm a TypeScript idiot. You can get the prototype from a TS class quite easily. I'll bet it's the same in ES6.

Here is some TS that you can try in the playground (http://www.typescriptlang.org/Playground) that proves it:

```
class Foo {
private _baz = 'original _baz';
get bar() { return true;}
get baz() { return 'first baz';} // type-safety placeholder; will be redefined
}

// You CAN get the prototype from the class!
var x = Foo.prototype;
console.log(x);

// baz has no setter at this point
let foo = new Foo();
console.log("foo.baz1:" + foo.baz); // "first baz"
foo.baz = "new value";
console.log("foo.baz2:" + foo.baz); // still "first baz"

/* redefinition has a setter and is no longer configurable */
Object.defineProperty(Foo.prototype, "baz", {
get: function () { return this._baz; },
set: function(value) {this._baz = value;},
enumerable: true,
configurable: false
});

// redefine `foo` with new version
foo = new Foo();
console.log("foo.baz3:" + foo.baz); // "original _baz"
foo.baz = "new _baz";
console.log("foo.baz4:" + foo.baz); // "new _baz"

```

Your comment counts.

You can add methods and properties to the ctors today. You don't have to add them to the initializer ... and I don't know why you would.

There is only a potential problem if the property has a **setter** and you do NOT want breeze to track it as an "unmapped property". Even then you can add such a property to the ctor AFTER registering with breeze client `MetadataStore`.

BTW, adding properties to a class later is kind of tricky in TS/ES6. The class constructor is not exposed by default so you can't grab it to add to the prototype.

Fear not, grasshopper! You can add a static method (in TS anyway) that exposes the ctor ... and mess with it anytime. I have no idea if the same game is viable in ES6.

I'm thinking out loud here. Given that Breeze has to rewrite the ctor anyway (in order to inject its goodness), I'm not quite sure how we're going to do this with TS or ES6 classes. We need that prototype.

Personally, when it gets funky like this, I'd chuck the class. This nonsense is one (among many reasons ... mix-ins being another) why I don't like classes and wish they had never been introduced. I was doing just fine with prototypes and I don't get the value of classes ... whereas the harm I see. Apparently I have company in Douglas Crockford.

Boo apparently I like Breeze too much and have posted too many votes in the past so I can't vote on this >.<