Pattern for constructing ES6 proxy objects as if by classical inheritance?

[ShadowthaKilla]

Although not finalized, I am experimenting with ES6 Proxies. My goal is to have a constructor function (one that utilizes classical inheritance like the one shown below) for creating proxy objects with inheritance chains.\[code\]function inherit(child, parent){ //a classical inheritance pattern var F = function(){}; F.prototype = parent.prototype; child.prototype = new F(); child.parent = parent.prototype; child.prototype.constructor = child; return child;}\[/code\]Does the following look sensible? I create an item and return the proxy from the constructor. Any method that would return a reference to the instance (for chaining purposes) must instead return a reference to the proxy, otherwise we lose the proxy while chaining.\[code\]function Item(attrs){ this.attrs = attrs; var proto = this.constructor.prototype; return this.proxy = Proxy.create(new MyHandler(this), proto);}Item.prototype.setStatus = function(status){ //do work return this.proxy; //we do this everywhere instead of a simple 'this'?}function DVD(attrs){ attrs.type = 'DVD'; return Item.call(this, attrs);}inherit(DVD, Item);var negotiator = new DVD({title: 'The Negotiator'}); //returns proxy\[/code\]The goal is to construct proxied objects (via the 'new' keyword) that may be products of a classical inheritance chain.Next issue. Consider what happens if I extend my Item prototype with Backbone.Events. Those imported methods are going to return \[code\]this\[/code\] instead of \[code\]this.proxy\[/code\]. To get around this, I must wrap all the imported methods returning \[code\]this\[/code\] in order to return the \[code\]proxy\[/code\] instead. This seems painful and error prone. Making use of the Proxy abstraction involves a lot of wiring, which doesn't seem quite right to me.While I love the Proxy concept, I am concerned with its practicality. Maybe I am missing some better practice for meeting my goals?