Fork me on GitHub
#cljs-dev
<
2019-08-26
>
dnolen13:08:04

@scknkkrer that ticket is probably not an easy one if you haven't done a lot of work on the compiler before

scknkkrer13:08:35

Actually, I’ve handle it well.

dnolen13:08:25

the two patches you have there are not the right way to approach the problem

4
scknkkrer13:08:25

But, if there are exceptions like . and ..; I have to know.

dnolen13:08:44

you should not be doing anything in parse-invoke for that ticket

scknkkrer13:08:48

I’m listening.

dnolen13:08:00

I'm going to reiterate one more time - this is an advanced ticket

dnolen13:08:57

before doing any more work, you should write a comment to describe exactly what you're intending to do to address the problem

dnolen13:08:18

it maybe also be that the scope is too wide and invasive for one ticket

dnolen13:08:46

but at the moment it's impossible to tell because there's no description of the problem besides my original annoyance

dnolen13:08:07

that deftype methods that start a . don't error and produce bad runtime code

dnolen13:08:10

@scknkkrer that ticket was badly described

dnolen13:08:17

which was my own fault - I've left a better description

scknkkrer13:08:32

So, you are saying that just deftype methods has to be limited against that check ?

dnolen13:08:37

I've also clarified where I think this might be meaningful

dnolen13:08:48

let's step back a second

dnolen13:08:57

(.foo ...) is nearly always fine

dnolen13:08:19

it's just a method call - there's no checking to do of any kind

dnolen13:08:31

(deftype Foo Object (.bar [] ...))

scknkkrer13:08:37

No, it was my fault. I should asked about it.

dnolen13:08:37

can't possible work

dnolen13:08:54

and the question is simply whether there are other similar cases

dnolen13:08:04

and whether the work could be combined - but maybe it can't

dnolen13:08:07

and we need separate tickets

scknkkrer13:08:16

**I’ve had should asked about it.

scknkkrer13:08:04

Ok, boss. I’m still volunteer for this problem.