These are chat archives for canjs/canjs

11th
Sep 2015
Justin Meyer
@justinbmeyer
Sep 11 2015 14:55 UTC
I'm talking about bitovi/canjs#1699
Mark Stahl
@mjstahl
Sep 11 2015 14:56 UTC

Okay, so it is better to say something along the lines of:

~key is going to provide a compute, if the property is a value, it will convert it to a compute that will update the property on a change.

Justin Meyer
@justinbmeyer
Sep 11 2015 14:56 UTC
which we are thinking of changing & to @ and * to ~
and we are dealing with new can.Map({ key: can.compute(1) })
what @key should look up
Mark Stahl
@mjstahl
Sep 11 2015 14:57 UTC
and new can.Map({ key: function() {} })
Justin Meyer
@justinbmeyer
Sep 11 2015 14:57 UTC
~key is going to provide a compute, if the property is a value, it will convert it to a compute that will update the property on a change.
~key1.key2 will provide a compute, a compute that updates when any observable in the "path" changes
I think ~ is pretty easily understood
Mark Stahl
@mjstahl
Sep 11 2015 14:59 UTC
Agreed. Hmm.. this may be a little trickier. @key1.key2 ?
Justin Meyer
@justinbmeyer
Sep 11 2015 14:59 UTC
compared to @
as ~ is basically what gets passed now to helpers
Mark Stahl
@mjstahl
Sep 11 2015 14:59 UTC
Yep, that is what I was just going to say
Justin Meyer
@justinbmeyer
Sep 11 2015 15:00 UTC
but yeah, @ ... part of me feels like it should be "one less magic" thing happens
in bitovi/canjs#1699
I give some foo.bar examples
look at the compute ones
what should @foo.bar give you?
@foo.bar
and do?
I see two options
  1. It returns 1, and keeps calling the helper if anything in the path changes.
#2. It returns the compute, and keeps calling if anything "above the compute" in the path changes
arg ... the 2nd 1. is supposed to be a 2
Mark Stahl
@mjstahl
Sep 11 2015 15:03 UTC
yep.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:03 UTC
so, I like #2
mostly because it feels the same as what happens with a function
var MyMap = Map.extend({bar: function(){  return this.attr("value") }})
{foo: new MyMap()}
Mark Stahl
@mjstahl
Sep 11 2015 15:04 UTC
Yes, I would agree.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:05 UTC
in this case, @foo.bar should return the bar function, and be updated if foo were to change
Mark Stahl
@mjstahl
Sep 11 2015 15:05 UTC
Okay, so let me through a wrench in this for a moment. Does this imply that I could do something like @foo.@bar if I just wanted 1?
Justin Meyer
@justinbmeyer
Sep 11 2015 15:05 UTC
(which in this case it can't b/c it's not part of an observable)
well, if you just wanted 1
you could actually do foo.bar
Mark Stahl
@mjstahl
Sep 11 2015 15:06 UTC
Oh yep, that's valid.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:07 UTC
well, foo.bar in a subexpression
yeah, I have big reservations about this
about how computes should be handled
with @
b/c I think people will see @ as a way to "give me the value"
mjstahl @mjstahl nods in agreement.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:08 UTC
but it's not, it's "do one less magical thing"
like ... don't do magic at the end of the path lookup
just leave it be
whatever is there ... give it to me
Mark Stahl
@mjstahl
Sep 11 2015 15:09 UTC
That is what I saying before... I don't even know if we need the extra syntax. Why not have that be the default.
?
Keep ~.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:09 UTC
well, I guess "subexpressions" are really going to be the way to get the "non-compute" value
have @ be the default?
b/c I want functions to be converted to computes
almost all the time
if I write
{{capitalize fullName}}
and fullName is a function
like return this.attr("first")+" "+this.attr("last")
Mark Stahl
@mjstahl
Sep 11 2015 15:11 UTC
sure
Justin Meyer
@justinbmeyer
Sep 11 2015 15:11 UTC
I dont want to pass the function, I want to pass the result
I guess @ makes sense
This message was deleted
regardless if that property/attribute points to a function or a comptue
whoops, meant to edit that
Mark Stahl
@mjstahl
Sep 11 2015 15:14 UTC
I look at it as "strict evaluation" of arguments. We are going to evaluate the arguments before passing them into another function/helper. A function and a compute would be treated no differently.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:15 UTC
yeah
I like this b/c there might be other things that need to be treated similarly
basically, these are values that normally have values w/i them that are more common to need
by default stache gets the internal values
but @ prevents that
this lines up with how can.compute.read works
Mark Stahl
@mjstahl
Sep 11 2015 15:16 UTC
I would argue that would should shoot for that (find other things that are treated similarly) because that will decrease the amount of confusion that /may/ be introduced by the change.
I already have a list for function / compute
anyhoo, I think this made things better
thanks for your help
Mark Stahl
@mjstahl
Sep 11 2015 15:19 UTC
Sorry I was distracted by some client stuff. It was fun, and I was glad I could help. I look forward to seeing how it turns out.
Justin Meyer
@justinbmeyer
Sep 11 2015 16:20 UTC
@mjstahl {{helper models@Todo~findAll}}
we could make stuff like that work
allow these things to substitute the normal (.) behavior
Mark Stahl
@mjstahl
Sep 11 2015 16:24 UTC
Yeah, I think that is the correct way to look at it. Larry Wall would be proud. ;)
Justin Meyer
@justinbmeyer
Sep 11 2015 19:23 UTC

we might follow Angular 2.0’s conventions

<component [(prop)]=“value”/>

two way

was that

one way

<component [prop]=“value” />

so (EVENT) will now bind on view-models

<component (prop)=“callSomething()”/>

you could do that, for instance, if prop changes in component

oh … I forgot to explain why we are doing this

so, originally, we wanted two-way binding to look like it currently does

<component prop=“{value}”/>

and to add one-way binding like:

<component prop=“{{value}}”/>

this causes problems :disappointed:

it interferes with how stache processing normally works

so we thought about changing one way binding to something more like:

<component prop=“[value]”/>

but this causes problem if we want one-way binding in something like <input value=“[key]”/>

we can’t actually set value to “[key]” temporarily

so the “modifiers” need to be on the attribute

the choice of [, ( simply reflects what angular chose

there’s a possibility I change [ to {

so things like {childProp}=“[parentPropertyName]"

looks reasonable

the good thing … is most attribute values would no longer need a decorator

we wouldn’t write can-click=“{foo bar}"

instead

($click)=“foo bar"

wrote all this in another chat room, but I wanted to talk about it here
Matthew Phillips
@matthewp
Sep 11 2015 19:24 UTC
cc @dylanrtt
Justin Meyer
@justinbmeyer
Sep 11 2015 19:25 UTC

@akagomez asked

Where did the $ come in?

($EVENT) would listen to dom events
be the equivalent of can-click
can-EVENT
(EVENT) listens to the viewModel
Kevin Phillips
@phillipskevin
Sep 11 2015 19:26 UTC
if we do that, where do we draw the line with matching angular 2’s template syntax?
Justin Meyer
@justinbmeyer
Sep 11 2015 19:26 UTC
not sure what you mean by that
we don't have to match angular's syntax ... we draw the line at doing what makes sense
but angular 2.0's binding syntax has advantageous over what's currently in 2.3
Kevin Phillips
@phillipskevin
Sep 11 2015 19:27 UTC
I just mean if a significant portion matches, but not everything, it will obviously be confusing for people that are familiar with one syntax trying to use the other
or transitioning from one to the other
Matthew Phillips
@matthewp
Sep 11 2015 19:28 UTC
dom events are much more common, maybe (EVENT) should be for dom
Justin Meyer
@justinbmeyer
Sep 11 2015 19:28 UTC
I think it would be over-all less confusing
stache doesn't exactly match Handlebars
I think it will be much easier for someone to know angular 2.0 to come to CanJS
Kevin Phillips
@phillipskevin
Sep 11 2015 19:29 UTC
no, I agree. I think if the angular 2 syntax solves the problems we’re looking at now it makes sense to match it on that.
Justin Meyer
@justinbmeyer
Sep 11 2015 19:29 UTC
if we have some similarities in what () vs [] means
but some of the finer things
like what you are suggesting ... binding on events
instead of view model
is changed
they still see that () means event binding
[] means one-way binding
[()] means two-way
so I agree that DOM binding is more common
but not more than two-way binding
let me break that down
Matthew Phillips
@matthewp
Sep 11 2015 19:30 UTC
btw, what does ~ do again, gets the value of a compute?
Justin Meyer
@justinbmeyer
Sep 11 2015 19:31 UTC
makes something pass a compute

One way binding

<component [one]="bar"/>

Two way view model binding

<component [(two)]="bar">
that would be the same as writing
<component  [two]="bar"
           (two)="~bar(@viewModel.two)" />

Two Way Attribute Binding

<input [($value)]="bar"/>
The same as:
<input [$value]="bar"
        ($input)="~bar($element.value)"/>
so here, hopefully you can see why we are using ($EVENT)
even though it's more common
In case it's not clear, there are two reason:
  1. Component bindings are a very common thing. So [()] needs to be small.
  2. We have an identifier most people would recognize as "element" -> $. I don't have something that represents "viewModel"
Justin Meyer
@justinbmeyer
Sep 11 2015 19:37 UTC
Thoughts :-) ?
Matthew Phillips
@matthewp
Sep 11 2015 19:37 UTC
digesting..
I think I said this last time we discussed binding, but I still don't see a huge value in one-way binding, I think this would be a lot simpler if we only worried about two-way and events
Justin Meyer
@justinbmeyer
Sep 11 2015 19:40 UTC
@matthewp I agree for the most part, but talking with a bunch of angular folks, this is an important feature
Matthew Phillips
@matthewp
Sep 11 2015 19:40 UTC
You can get one-way binding in the viewModel with a setter if you need it
Justin Meyer
@justinbmeyer
Sep 11 2015 19:41 UTC
when dealing with "less" careful developers
you want to call their control ... and not have it talk back to your data
Matthew Phillips
@matthewp
Sep 11 2015 19:41 UTC
do you still have that link?
I'm not sure what you mean about one-way binding done in the view model
Matthew Phillips
@matthewp
Sep 11 2015 19:42 UTC
I guess I see that
it makes one way the default
how do you post code in gitter.
Justin Meyer
@justinbmeyer
Sep 11 2015 19:43 UTC
like github
```
Matthew Phillips
@matthewp
Sep 11 2015 19:44 UTC
ok, let's prevent [two] is two way
i would make it one way by doing
```<component [two]="bar"
arg
<component [two]="bar"/>
and in my viewModel
bar: {
  set: function(val){
    this.attr("otherBar", val())
  }
}
essentially I would have one way binding by not manipulating "bar" ever
but, I do see the argument for safety and not making two-way the norm
so would these be equivalent
<component [(two)]="bar"/>

<component two="{bar}"/>
and drop the latter in 3.0
Justin Meyer
@justinbmeyer
Sep 11 2015 19:50 UTC
?
did you mean to say "let's prevent [two]'s two-way binding"?
Matthew Phillips
@matthewp
Sep 11 2015 19:51 UTC
i meant let's pretend
Justin Meyer
@justinbmeyer
Sep 11 2015 19:52 UTC
I'm not sure what you are saying
in your "parent view model"?
why would val be a compute?
Matthew Phillips
@matthewp
Sep 11 2015 19:53 UTC
i guess it wouldn't be a compute
but i take back that comment
because that puts the onus on the child viewmodel to control one-way
Justin Meyer
@justinbmeyer
Sep 11 2015 19:54 UTC
how would bar be able to get a value from it's parent?
and update itself?
if the parent was like <parent [bar]="something"/>
if something changed, bar would never change in parent
Matthew Phillips
@matthewp
Sep 11 2015 19:55 UTC
i was saying that if we only had two-way binding and [bar] was a two-way syntax
Justin Meyer
@justinbmeyer
Sep 11 2015 19:55 UTC
yeah, I got that
Matthew Phillips
@matthewp
Sep 11 2015 19:55 UTC
so if they are two way bound and something changed, bar would get changed too
Justin Meyer
@justinbmeyer
Sep 11 2015 19:56 UTC
it wouldn't
not with that setter
Matthew Phillips
@matthewp
Sep 11 2015 19:56 UTC
the point of that setter is to have one-way from the parent
Justin Meyer
@justinbmeyer
Sep 11 2015 19:56 UTC
I don't think I'm making sense
lets clarify ...
your html looks like
<master>
  <parent [bar]="something">
    <child [two]="bar">
And parent's viewModel has something like:
bar: {
  set: function(val){
    this.attr("otherBar", val())
  }
}
right?
master has a "something" value ... lets say it's set to 1
Matthew Phillips
@matthewp
Sep 11 2015 19:59 UTC
sounds right
Justin Meyer
@justinbmeyer
Sep 11 2015 19:59 UTC
say, master changes it to 2
<parent>'s bar.set is going to be called
which will never actually create a "bar" event ... which will never change two in <child>
Matthew Phillips
@matthewp
Sep 11 2015 20:00 UTC
why won't it create a bar event?
Justin Meyer
@justinbmeyer
Sep 11 2015 20:00 UTC
because your setter doesn't actually set bar
Matthew Phillips
@matthewp
Sep 11 2015 20:00 UTC
oh, missing a return val in the setter
if you return val it will
Justin Meyer
@justinbmeyer
Sep 11 2015 20:01 UTC
yeah, bar would always be undefined
ok ... well this is why i was confused
ok, so why is two-way binding turned off then?
if you add in a return?
Matthew Phillips
@matthewp
Sep 11 2015 20:01 UTC
what I was saying is that you can mimic one-way binding by not manipulating a two-way bound property
Justin Meyer
@justinbmeyer
Sep 11 2015 20:02 UTC
but you are
Matthew Phillips
@matthewp
Sep 11 2015 20:02 UTC
it's turned off because I never change bar
Justin Meyer
@justinbmeyer
Sep 11 2015 20:02 UTC
if you add in the return
but you need to change bar
if the parent is setting it
that's the problem
you can't tell if its the parent
or the child
doing the setting
so you either turn everything off
or all of it
Matthew Phillips
@matthewp
Sep 11 2015 20:02 UTC
yes, that's the problem
you have to have control of all of the components
and you have to be careful, like you said
Justin Meyer
@justinbmeyer
Sep 11 2015 20:03 UTC
yeah, the whole no-shared-state
is very popular
two way bindings explode that idea
I think it's a feature worth having
Matthew Phillips
@matthewp
Sep 11 2015 20:04 UTC
so back to my last question, first are these two equivalent
<component [(two)]="bar"/>

<component two="{bar}"/>
I think they are, and do we drop the latter in 3.0
Justin Meyer
@justinbmeyer
Sep 11 2015 20:05 UTC
@pYr0x welcome
@dylanrtt welcome too :-)
let me know if either of you want to talk about @, ~, or maybe some & or *
@matthewp yes, those are the same
I don't think we drop it
Until 4.0
Julian
@pYr0x
Sep 11 2015 20:47 UTC
Sp
i am there
I think we have to
Justin Meyer
@justinbmeyer
Sep 11 2015 20:52 UTC

I think we have to

drop the old one?

@pYr0x
?
Julian
@pYr0x
Sep 11 2015 20:53 UTC
Make canjs readable for other users
Justin Meyer
@justinbmeyer
Sep 11 2015 20:53 UTC
oh, are you referring to @phillipskevin 's comments?
Julian
@pYr0x
Sep 11 2015 20:54 UTC
havent read it
Justin Meyer
@justinbmeyer
Sep 11 2015 20:54 UTC
oh ... so maybe I missed what you are referring to
Julian
@pYr0x
Sep 11 2015 20:54 UTC
But other users from angular js or other languages
Julian
@pYr0x
Sep 11 2015 20:55 UTC
can have it easyer
Justin Meyer
@justinbmeyer
Sep 11 2015 20:55 UTC
yeah
that's why @phillipskevin was talking about
why/what
any more thoughts on @/~ */&
Julian
@pYr0x
Sep 11 2015 20:56 UTC
I agree that your example with model looks nicer
But I think the compatibility to other languages beat it
Justin Meyer
@justinbmeyer
Sep 11 2015 21:06 UTC
@pYr0x yeah, but this doesn't map to other languages
especially not C's & and *
Julian
@pYr0x
Sep 11 2015 21:06 UTC
I thought angular uses the &
?
php uses &I for reference also
Justin Meyer
@justinbmeyer
Sep 11 2015 21:07 UTC
ah, yeah, angular isn't a language
Julian
@pYr0x
Sep 11 2015 21:07 UTC
:)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:09 UTC
this is how we reasoned about it earlier

the problem is that currently, the proposal relies on the names

& = reference … GET ME A REFERENCE
* = dereference … DO THE OPPOSITE … what is the opposite … well it must be get me a compute

You are more closely aligning to the actual behavior of & and *

& = return pointer address … pointers are more abstract then values … RETURN A COMPUTE
* = make variable value as pointed to by reference …. function is actual value …. RETURN A FUNCTION

it seems like if you come at it from the names … you land at the current proposal … if you come at it from actually knowing C … you land at yours

cc @mjstahl
Kevin Phillips
@phillipskevin
Sep 11 2015 21:10 UTC
to pile on that, I think trying to match other frameworks’ template syntax will be a much bigger benefit than trying to match other languages based on terminology (reference, dereference, etc)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:10 UTC
@phillipskevin you've split yourself :-)
angular has & and *
which I think is wrong
Kevin Phillips
@phillipskevin
Sep 11 2015 21:10 UTC
oh, it has both?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:10 UTC
which is also based on other languages
Kevin Phillips
@phillipskevin
Sep 11 2015 21:11 UTC
well, then I don’t know what I think
Justin Meyer
@justinbmeyer
Sep 11 2015 21:11 UTC
haha
the problem to me is that ... I know C, and I will get & and * messed up in how they apply to can.stache
Kevin Phillips
@phillipskevin
Sep 11 2015 21:11 UTC
I see the * in the Angular 2 doc
Justin Meyer
@justinbmeyer
Sep 11 2015 21:11 UTC
it's not beneficial
if that's the case
Kevin Phillips
@phillipskevin
Sep 11 2015 21:12 UTC
right
Justin Meyer
@justinbmeyer
Sep 11 2015 21:12 UTC
b/c knowing C actually hurts
Kevin Phillips
@phillipskevin
Sep 11 2015 21:12 UTC
that’s kind of always the case, but it applies double in this case
Julian
@pYr0x
Sep 11 2015 21:14 UTC
Hm
Kevin Phillips
@phillipskevin
Sep 11 2015 21:14 UTC
but yeah, I don’t think we should try to use & and * in relation to referencing/dereferencing
Julian
@pYr0x
Sep 11 2015 21:15 UTC
Why not?
Kevin Phillips
@phillipskevin
Sep 11 2015 21:17 UTC
just because of how easy it is for someone to understand it backwards
Julian
@pYr0x
Sep 11 2015 21:19 UTC
Sorry don't understand ..
you want to have & and *?
didnt get it ..:/
Kevin Phillips
@phillipskevin
Sep 11 2015 21:21 UTC

the problem is that currently, the proposal relies on the names

& = reference … GET ME A REFERENCE
* = dereference … DO THE OPPOSITE … what is the opposite … well it must be get me a compute

You are more closely aligning to the actual behavior of & and *

& = return pointer address … pointers are more abstract then values … RETURN A COMPUTE
* = make variable value as pointed to by reference …. function is actual value …. RETURN A FUNCTION

it seems like if you come at it from the names … you land at the current proposal … if you come at it from actually knowing C … you land at yours

I was agreeing with this… & and * can be interpreted one way or the other
@justinbmeyer with the Angular 2 [...] and (...) and [(...)] syntax, there’s still a need for some syntax to determine whether you’re given a compute or not, right?
Kevin Phillips
@phillipskevin
Sep 11 2015 21:31 UTC
or could 1-way binding always give a value and 2-way binding always give a compute?
Julian
@pYr0x
Sep 11 2015 21:33 UTC
where the @ and ~ came from?
i saw @ in annotations in typescript
i think we should follow the main stream
Kevin Phillips
@phillipskevin
Sep 11 2015 21:34 UTC
I think it was just an attempt to avoid & and * so that people don’t already have pre-conceived ideas of what they mean
from C
Julian
@pYr0x
Sep 11 2015 21:35 UTC
and for now the main stream is angular 2.0
Kevin Phillips
@phillipskevin
Sep 11 2015 21:35 UTC
I don’t think @ means anything in a template in angular
it’s just for annotations within JS
Julian
@pYr0x
Sep 11 2015 21:44 UTC
why we do not a mixin
{{helper models&Todo~findAll}}
where the most codes came from? c? i dont think so
php, python, node?
crazy idea: what about the ->
{{helper models&Todo->findAll}}
Justin Meyer
@justinbmeyer
Sep 11 2015 21:47 UTC
@pYr0x there's a context
I wouldn't want people to have to write ->fullName
{{->fullName}}
that looks strange
& is an operator
if we ever wanted to support bitwise operators
(not saying we should)
Julian
@pYr0x
Sep 11 2015 21:49 UTC
never used bitwise operations
Justin Meyer
@justinbmeyer
Sep 11 2015 21:49 UTC
the parsing becomes harder
I have ... jQuery++'s "compare" provides a bitmap
IE provides a bitmap for event.button
Julian
@pYr0x
Sep 11 2015 21:50 UTC
but do you not think is better for people knowing angular
Justin Meyer
@justinbmeyer
Sep 11 2015 21:50 UTC
it is
better for people who know angular
Julian
@pYr0x
Sep 11 2015 21:51 UTC
do angular using the * ?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:51 UTC
but angular has made mistakes
so have we
I think & and * are a mistake
Julian
@pYr0x
Sep 11 2015 21:52 UTC
@ seems to me more like.. to get the value directly
and not by reference
Justin Meyer
@justinbmeyer
Sep 11 2015 21:52 UTC
yep
that's exactly what @ will do
@fullName -> returns a fullName function
to be clear "everything" in JS is a reference
Julian
@pYr0x
Sep 11 2015 21:52 UTC
i thought we just talking about refrence?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:53 UTC
this is another reason why I think talking about a "reference" operator makes no sense
Julian
@pYr0x
Sep 11 2015 21:53 UTC
a reference in stache
Justin Meyer
@justinbmeyer
Sep 11 2015 21:53 UTC
still, I'm not sure what that even is
as everything is a reference
the function that might be returned is still a reference to a function
Julian
@pYr0x
Sep 11 2015 21:54 UTC
hm
Justin Meyer
@justinbmeyer
Sep 11 2015 21:54 UTC
{{helper fullName}}
Julian
@pYr0x
Sep 11 2015 21:54 UTC
make sens
Justin Meyer
@justinbmeyer
Sep 11 2015 21:54 UTC
helper(arg)
if arg is a function, or a compute, in both cases arg is still a reference
Julian
@pYr0x
Sep 11 2015 21:55 UTC
ok
i am persuade
;)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:56 UTC
ha, yeah, I reached for & and * too
but people at bitovi convinced me this was a bad idea
well, not bad
just confusing
Julian
@pYr0x
Sep 11 2015 21:56 UTC
;)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:57 UTC
it's like this in JS
it's totally unlike this in Java
or many other languages
Julian
@pYr0x
Sep 11 2015 21:57 UTC
yes
Justin Meyer
@justinbmeyer
Sep 11 2015 21:57 UTC
they should have called it something different
Julian
@pYr0x
Sep 11 2015 21:58 UTC
self
Justin Meyer
@justinbmeyer
Sep 11 2015 21:58 UTC
so people wouldn't have the connotation
Julian
@pYr0x
Sep 11 2015 21:58 UTC
mybe
whats about the two and one way binding?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:58 UTC
yeah, it's worse in the long run to pretend to be something you are not
Julian
@pYr0x
Sep 11 2015 21:59 UTC
do you follow the angular guidline?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:59 UTC
yeah, probably
something similar
I'm going to write up an issue
once I get this crazy baby off my lap
Julian
@pYr0x
Sep 11 2015 21:59 UTC
:D
gave it your wife
Justin Meyer
@justinbmeyer
Sep 11 2015 22:00 UTC
wife is out
going to go for a walk
back in 30
Julian
@pYr0x
Sep 11 2015 22:01 UTC
so i like the [] and () more than the {{
so have to go to bed. its 0 o clock in germany
;)
gn8