Skip to content

Instantly share code, notes, and snippets.

@brianleroux
Created October 13, 2010 22:53
Show Gist options
  • Save brianleroux/625120 to your computer and use it in GitHub Desktop.
Save brianleroux/625120 to your computer and use it in GitHub Desktop.
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');
};
@mindscratch
Copy link

I like the approach here.

@brianleroux
Copy link
Author

thx

@creationix
Copy link

Very nice.

Just a couple of technical nit-picks, is there a reason you're replacing the prototype from within the constructor. I haven't seen that pattern. Also instead of var emailActivationCode = function() do function emailActivationCode() and get named functions in your stack traces as well as shorter definitions.

Again, very nice, those were just constructive criticism.

@brianleroux
Copy link
Author

Yeah, it only half works at the moment. Getting a reference of object from an outside closure was... interesting. I suppose I should post that hack somewhere. Just a fun experiment really. =) Agree w/ both points on feedback. No reason for working the prototype in the ctor other than it looks pretty. ;)

@creationix
Copy link

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.

@brianleroux
Copy link
Author

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.

@isaacs
Copy link

isaacs commented Oct 14, 2010

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){...}}).

@creationix
Copy link

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)

@aglemann
Copy link

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

@brianleroux
Copy link
Author

@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

@isaacs
Copy link

isaacs commented Oct 14, 2010

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?

@creationix
Copy link

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.

@brianleroux
Copy link
Author

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?

@creationix
Copy link

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.

@brianleroux
Copy link
Author

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.

@creationix
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment