These are chat archives for ericelliott/stampit

22nd
Jan 2015
Vasyl Boroviak
@koresar
Jan 22 2015 01:02
Are you talking about fixed.state and fixed.methods, or about stampit.state() and stampit.methods()?
Vasyl Boroviak
@koresar
Jan 22 2015 01:08
In case of fixed.methods the variable is used as prototype for the stamped objects. Whereas the fixed.state is being deep cloned for each new object.
John Fawcett
@jrf0110
Jan 22 2015 02:19
I suppose I was talking about stampit.state()/.methods(); When we stamp out a new object, is .methods shallow cloned and .state deep cloned?

What would stop someone from doing something like:

```javascript

ah crap.
Talon
@talon
Jan 22 2015 02:20
invalid syntax
:P
John Fawcett
@jrf0110
Jan 22 2015 02:20
var cars = stampit()
  .state({
    drive: function(){ ... }
  })
vs:
var cars = stampit()
  .methods({
    drive: function(){ ... }
  })
Vasyl Boroviak
@koresar
Jan 22 2015 02:22
You will end up with the following object.
John Fawcett
@jrf0110
Jan 22 2015 02:22
I understand the conceptual difference between the two - I'm just using .state for the "data that changes per instance" aspect and .methods for things that need to carry from instance-to-instance
But I got to asking myself what is the technical difference
s/technical/intended
Vasyl Boroviak
@koresar
Jan 22 2015 02:22
That's correct.
John Fawcett
@jrf0110
Jan 22 2015 02:23
I've been also putting members on my stamps that are not methods at all
via .methods
something that should be shared from instance-to-instance
say, an http client to some api
Vasyl Boroviak
@koresar
Jan 22 2015 02:23
hm...
John Fawcett
@jrf0110
Jan 22 2015 02:24
It works out completely fine
and that prompted my original question
Vasyl Boroviak
@koresar
Jan 22 2015 02:24
I believe you have clear understanding of what's going underneath.
John Fawcett
@jrf0110
Jan 22 2015 02:25
Well, thank you :)
Vasyl Boroviak
@koresar
Jan 22 2015 02:25
.methods() a mixed into prototype of your objects. And state and cloned per each new object, never making it into prototype.
a===are
and=gets
John Fawcett
@jrf0110
Jan 22 2015 02:26
These objects are created via Object.create(), right?
Vasyl Boroviak
@koresar
Jan 22 2015 02:26
right
John Fawcett
@jrf0110
Jan 22 2015 02:26
So, things specified in .methods() make it directly into Object.create(...) while .state() is set after the creation?
Vasyl Boroviak
@koresar
Jan 22 2015 02:26
var newObj = mixin(Object.create(fixed.methods), clone(fixed.state));
John Fawcett
@jrf0110
Jan 22 2015 02:27
gotcha
I see
Then I believe the nomenclature for stampit could use some revising
Indeed. What's your proposal?
John Fawcett
@jrf0110
Jan 22 2015 02:28
swap .methods() with .proto()
Vasyl Boroviak
@koresar
Jan 22 2015 02:28
+100500 :)
John Fawcett
@jrf0110
Jan 22 2015 02:28
To imply that anything that would go on the prototype could go there
Vasyl Boroviak
@koresar
Jan 22 2015 02:28
I mean I agree.
John Fawcett
@jrf0110
Jan 22 2015 02:28
hah
and not just methods
Talon
@talon
Jan 22 2015 02:28
I feel like a PR that aliases those might get excepted
Vasyl Boroviak
@koresar
Jan 22 2015 02:28
In fact there is a PR by me which fixes the issue.
John Fawcett
@jrf0110
Jan 22 2015 02:29
oh very cool
Vasyl Boroviak
@koresar
Jan 22 2015 02:29
ericelliott/stampit#48
See the changes to the factory()
John Fawcett
@jrf0110
Jan 22 2015 02:30
Boof - that's a beefy PR - I'll take a looksie
^ Don't mean any disrespect there! Just saying it's a big diff :)
Vasyl Boroviak
@koresar
Jan 22 2015 02:30
TL;DR: For methods it uses new function mixInFunctions instead of mixIn.
It mixes functions only ignoring the rest of the properties.
Whereas it would be good to introduce a function stampit.proto() to manipulate the fixed.methods directly. People (like you) would definitely need it.
So that .proto() would mix in everything is was given.
Regarding the PR. The Tl;DR looks like following:
John Fawcett
@jrf0110
Jan 22 2015 02:35
Just did a little more reading (and please excuse my ignorance, I just started using stampit this afternoon), Is the current implementation of .methods() any different than .mixIn()?
Vasyl Boroviak
@koresar
Jan 22 2015 02:36
yes.
It uses minInChain. It takes all the properties including those in the prototype chain. I.e. it does not do hasOwnProperty checks.
John Fawcett
@jrf0110
Jan 22 2015 02:38
Alrighty. I think that clears up everything for me
Thanks, @koresar
Vasyl Boroviak
@koresar
Jan 22 2015 02:41
Regarding the PR #48. The Tl;DR looks like following:
1) stamp.methods() uses functions only and does not dive into prototype chain.
2) All stamps are immutable now (changing one stamp would not change another).
3) All chaining functions (like stamp.methods()) return a new stamp now, i.e. does not change this.
John Fawcett
@jrf0110
Jan 22 2015 02:43

Another question - How are you guys using this in practice?

One way would be a more traditional Object-Oriented Components design pattern where you have all these component subclasses (individual behavior prototypes in JS), and a huge aggregate class that brings them all together. Contrived example - Car is made up of Steering, RigidBody, Transmission components.

Another way would be more of an on-demand approach. Depending on the needs of the code, a particular version of multiple prototypes are stamped out (perhaps your car only needs Steering and RigidBody). The resulting object would sort of have its composed prototype defined on-the-fly.

I'm just curious about other folks' code layout and usage
Vasyl Boroviak
@koresar
Jan 22 2015 02:46
But these people are using stampit powers at its full: https://github.com/asaf/nodejs-model/blob/master/lib/model.coffee
Vasyl Boroviak
@koresar
Jan 22 2015 03:30
No, they are not. I was wrong. Sorry.