These are chat archives for canjs/canjs

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

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
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
and new can.Map({ key: function() {} })
Justin Meyer
@justinbmeyer
Sep 11 2015 14:57
~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
Agreed. Hmm.. this may be a little trickier. @key1.key2 ?
Justin Meyer
@justinbmeyer
Sep 11 2015 14:59
compared to @
as ~ is basically what gets passed now to helpers
Mark Stahl
@mjstahl
Sep 11 2015 14:59
Yep, that is what I was just going to say
Justin Meyer
@justinbmeyer
Sep 11 2015 15:00
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
yep.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:03
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
Yes, I would agree.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:05
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
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
(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
Oh yep, that's valid.
Justin Meyer
@justinbmeyer
Sep 11 2015 15:07
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
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
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
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
sure
Justin Meyer
@justinbmeyer
Sep 11 2015 15:11
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
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
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
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
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
@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
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

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
cc @dylanrtt
Justin Meyer
@justinbmeyer
Sep 11 2015 19:25

@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
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
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
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
dom events are much more common, maybe (EVENT) should be for dom
Justin Meyer
@justinbmeyer
Sep 11 2015 19:28
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
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
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
btw, what does ~ do again, gets the value of a compute?
Justin Meyer
@justinbmeyer
Sep 11 2015 19:31
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
Thoughts :-) ?
Matthew Phillips
@matthewp
Sep 11 2015 19:37
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
@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
You can get one-way binding in the viewModel with a setter if you need it
Justin Meyer
@justinbmeyer
Sep 11 2015 19:41
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
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
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
like github
```
Matthew Phillips
@matthewp
Sep 11 2015 19:44
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
?
did you mean to say "let's prevent [two]'s two-way binding"?
Matthew Phillips
@matthewp
Sep 11 2015 19:51
i meant let's pretend
Justin Meyer
@justinbmeyer
Sep 11 2015 19:52
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
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
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
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
yeah, I got that
Matthew Phillips
@matthewp
Sep 11 2015 19:55
so if they are two way bound and something changed, bar would get changed too
Justin Meyer
@justinbmeyer
Sep 11 2015 19:56
it wouldn't
not with that setter
Matthew Phillips
@matthewp
Sep 11 2015 19:56
the point of that setter is to have one-way from the parent
Justin Meyer
@justinbmeyer
Sep 11 2015 19:56
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
sounds right
Justin Meyer
@justinbmeyer
Sep 11 2015 19:59
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
why won't it create a bar event?
Justin Meyer
@justinbmeyer
Sep 11 2015 20:00
because your setter doesn't actually set bar
Matthew Phillips
@matthewp
Sep 11 2015 20:00
oh, missing a return val in the setter
if you return val it will
Justin Meyer
@justinbmeyer
Sep 11 2015 20:01
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
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
but you are
Matthew Phillips
@matthewp
Sep 11 2015 20:02
it's turned off because I never change bar
Justin Meyer
@justinbmeyer
Sep 11 2015 20:02
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
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
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
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
@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
Sp
i am there
I think we have to
Justin Meyer
@justinbmeyer
Sep 11 2015 20:52

I think we have to

drop the old one?

@pYr0x
?
Julian
@pYr0x
Sep 11 2015 20:53
Make canjs readable for other users
Justin Meyer
@justinbmeyer
Sep 11 2015 20:53
oh, are you referring to @phillipskevin 's comments?
Julian
@pYr0x
Sep 11 2015 20:54
havent read it
Justin Meyer
@justinbmeyer
Sep 11 2015 20:54
oh ... so maybe I missed what you are referring to
Julian
@pYr0x
Sep 11 2015 20:54
But other users from angular js or other languages
Julian
@pYr0x
Sep 11 2015 20:55
can have it easyer
Justin Meyer
@justinbmeyer
Sep 11 2015 20:55
yeah
that's why @phillipskevin was talking about
why/what
any more thoughts on @/~ */&
Julian
@pYr0x
Sep 11 2015 20:56
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
@pYr0x yeah, but this doesn't map to other languages
especially not C's & and *
Julian
@pYr0x
Sep 11 2015 21:06
I thought angular uses the &
?
php uses &I for reference also
Justin Meyer
@justinbmeyer
Sep 11 2015 21:07
ah, yeah, angular isn't a language
Julian
@pYr0x
Sep 11 2015 21:07
:)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:09
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
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
@phillipskevin you've split yourself :-)
angular has & and *
which I think is wrong
Kevin Phillips
@phillipskevin
Sep 11 2015 21:10
oh, it has both?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:10
which is also based on other languages
Kevin Phillips
@phillipskevin
Sep 11 2015 21:11
well, then I don’t know what I think
Justin Meyer
@justinbmeyer
Sep 11 2015 21:11
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
I see the * in the Angular 2 doc
Justin Meyer
@justinbmeyer
Sep 11 2015 21:11
it's not beneficial
if that's the case
Kevin Phillips
@phillipskevin
Sep 11 2015 21:12
right
Justin Meyer
@justinbmeyer
Sep 11 2015 21:12
b/c knowing C actually hurts
Kevin Phillips
@phillipskevin
Sep 11 2015 21:12
that’s kind of always the case, but it applies double in this case
Julian
@pYr0x
Sep 11 2015 21:14
Hm
Kevin Phillips
@phillipskevin
Sep 11 2015 21:14
but yeah, I don’t think we should try to use & and * in relation to referencing/dereferencing
Julian
@pYr0x
Sep 11 2015 21:15
Why not?
Kevin Phillips
@phillipskevin
Sep 11 2015 21:17
just because of how easy it is for someone to understand it backwards
Julian
@pYr0x
Sep 11 2015 21:19
Sorry don't understand ..
you want to have & and *?
didnt get it ..:/
Kevin Phillips
@phillipskevin
Sep 11 2015 21:21

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
or could 1-way binding always give a value and 2-way binding always give a compute?
Julian
@pYr0x
Sep 11 2015 21:33
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
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
and for now the main stream is angular 2.0
Kevin Phillips
@phillipskevin
Sep 11 2015 21:35
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
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
@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
never used bitwise operations
Justin Meyer
@justinbmeyer
Sep 11 2015 21:49
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
but do you not think is better for people knowing angular
Justin Meyer
@justinbmeyer
Sep 11 2015 21:50
it is
better for people who know angular
Julian
@pYr0x
Sep 11 2015 21:51
do angular using the * ?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:51
but angular has made mistakes
so have we
I think & and * are a mistake
Julian
@pYr0x
Sep 11 2015 21:52
@ seems to me more like.. to get the value directly
and not by reference
Justin Meyer
@justinbmeyer
Sep 11 2015 21:52
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
i thought we just talking about refrence?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:53
this is another reason why I think talking about a "reference" operator makes no sense
Julian
@pYr0x
Sep 11 2015 21:53
a reference in stache
Justin Meyer
@justinbmeyer
Sep 11 2015 21:53
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
hm
Justin Meyer
@justinbmeyer
Sep 11 2015 21:54
{{helper fullName}}
Julian
@pYr0x
Sep 11 2015 21:54
make sens
Justin Meyer
@justinbmeyer
Sep 11 2015 21:54
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
ok
i am persuade
;)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:56
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
;)
Justin Meyer
@justinbmeyer
Sep 11 2015 21:57
it's like this in JS
it's totally unlike this in Java
or many other languages
Julian
@pYr0x
Sep 11 2015 21:57
yes
Justin Meyer
@justinbmeyer
Sep 11 2015 21:57
they should have called it something different
Julian
@pYr0x
Sep 11 2015 21:58
self
Justin Meyer
@justinbmeyer
Sep 11 2015 21:58
so people wouldn't have the connotation
Julian
@pYr0x
Sep 11 2015 21:58
mybe
whats about the two and one way binding?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:58
yeah, it's worse in the long run to pretend to be something you are not
Julian
@pYr0x
Sep 11 2015 21:59
do you follow the angular guidline?
Justin Meyer
@justinbmeyer
Sep 11 2015 21:59
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
:D
gave it your wife
Justin Meyer
@justinbmeyer
Sep 11 2015 22:00
wife is out
going to go for a walk
back in 30
Julian
@pYr0x
Sep 11 2015 22:01
so i like the [] and () more than the {{
so have to go to bed. its 0 o clock in germany
;)
gn8