person.js

function Person() {
    
    // properties and validations
    attr(
        { id:Number, unique:true, nullable:false },
        { email:String, unique:true, nullable:false, min:1, max:55, format:'[a-b]' },
        { salt:String }, 
        { pswd:String },
        { active:Boolean, init:false },
        { tags:Array }
    );
    
    // helpful property declarations
    timestamp();
    
    // callbacks
    creating({ before:poundSalt, after:emailActivationCode });
    updating();
    deleting();

    // a private function to generate a unique salt for hashing the password, called in 'creating' callback
    // testable therefore by the creating callback?
    var poundSalt = function(obj) {
        
    };
    
    // emails an activation code 
    var emailActivationCode = function(obj) {
        
    };
    
    
    var forgotPassword = function(obj) {
        
    };
    
    // public instance attributes
    this.prototype = {
        // activates the user account
        get active() {

        },
        set active() {

        }        
    }
    
    // views, beautiful custom finders
    view('tags', { map:function(){}, reduce:function(){} });
    view('popular');
};

https://gist.github.com/fba9a6950fc8272c36f1 will use the inherited getter, but yeah, I hadn't noticed that it was this.prototype getting assigned. That's simply a prototype property that gets created on each instance object. It has no special meaning by itself unless the framework underneath does something with it.

Anyway like brianleroux said, the point of the gist was the concept, the the particular implementation.

ha! so it is. no, no magic. again this is just playing around. proto is probably the desired behavior to do but... whatever. Did I mention that this is toy code? =) Anyhow, I do appreciate the thorough debug. Any thoughts on the API style?

Brian, so are you using with internally to make all the magic attr timestamp and friends. If so, could we get close to this syntax but still be es5 strict capable?

Also if you are doing a demcompile + with + eval trick to change the scope (like here http://gist.github.com/199372), then this will cause issues with people using the library, because suddenly they can't get to closures from their local file.

Maybe instead of this.prototype = {…} just return the object you want exposed. Then the model system will call the function with a custom "this" scope and that's where you can put the magic meta functions. Also have a chance to modify the object after it's created and returned.

I left work so I actually do not remember how I made it sort work but essentially it was some runtime recompilation. Yes: evil. But this is just a thought experiment.

Another way would be to create a magical methods() method that accepts an obj for mixing into the __proto__. Meh.

The combinations of Proxy and Reflect make this sort of business pretty easy... I do hope those innovations make it into the language proper.

I created a fork with some style changes. Also I noticed the views section. What exactly do they do?