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');
};

I think declarative patterns like this are the way to solve the code complexity issue that non-blocking I/O has caused. Our code should describe what we want done and less exactly how to do it. Otherwise it will get unmaintainable very quickly.

Agree; we have a great foundation with Node and now it is now time to start thinking about the nicer abstractions. Pretty much any part of Node (or any js project really) could really benefit from thinking about how the API gets used and making things more expressive in terms of what we want code to do without resorting to comments to explain it. This is what self documenting code looks like. (to me anyhow) No gimmicky framework bs, code ceremony or deep namespacing. Just clear expressive code. Fuck I should really write a blog.

I don't grok the purpose of this.prototype = {some object} inside a constructor. If you did p = new Person(), then this.prototype is p.prototype, whereas I think what you mean to do is set Person.prototype aka p.__proto__ (in browsers that support __proto__ anyhow.)

If you want to assign a getter/setter on the object itself, you should use Object.defineProperty(this, "active", {get:function(){...}, set:function(v){...}}).

You could even go meta and do a ruby style attr_accessor. not sure if it's a good idea, but it's possible with ES5. (probably not with strict mode though)

Re: the named functions for your stack traces... the way I thought to solve that... was if the Model and everything else extended an abstract Class (for OO goodness) the Class could do the work of iterating over methods and tagging with a property like name. If that doesn't make sense you can see what it looks like here:

http://github.com/aglemann/js-oo/blob/master/lib/oo.js

Inspired by something I saw here: http://gist.github.com/434689

@isaacs: its just playing around with syntax. JS has a lot of gross syntactic ceremony and I was trying literally everything to minimize that with a working model.

p.prototype would work and, really, it is not a big deal. Messy perhaps with big collections or something. Maybe not. Depends on how you use it. Anyhow, its just playing around --- tho there is some imp code that works for basic crud against a couch. shrug

In what sense would p.prototype "work"? I mean, with this, if you did p = new Person ; p.active = foo then the setter will not fire, and var x = p.active will set x to undefined. Or are you suggesting some cleverness where setting Person.prototype.prototype is a magical setter?

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?