This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-03
Channels
- # aatree (5)
- # admin-announcements (52)
- # announcements (1)
- # aws (2)
- # beginners (55)
- # boot (494)
- # braid-chat (17)
- # cider (2)
- # cljsjs (4)
- # cljsrn (8)
- # clojure (157)
- # clojure-austin (6)
- # clojure-czech (7)
- # clojure-denmark (1)
- # clojure-dev (102)
- # clojure-ireland (6)
- # clojure-japan (4)
- # clojure-miami (2)
- # clojure-poland (90)
- # clojure-russia (415)
- # clojurebridge (2)
- # clojurescript (143)
- # core-async (1)
- # datavis (4)
- # datomic (20)
- # devcards (5)
- # dirac (40)
- # emacs (9)
- # events (103)
- # gorilla (1)
- # immutant (122)
- # jobs (3)
- # ldnclj (20)
- # lein-figwheel (1)
- # mount (2)
- # off-topic (22)
- # om (170)
- # onyx (7)
- # overtone (6)
- # parinfer (100)
- # proton (2)
- # re-frame (5)
- # reagent (32)
- # ring-swagger (2)
- # spacemacs (6)
@alexmiller: hey, thanks for your comments on CLJ-440. I had not considered AOT and compatibility.
yeah, there are a few places that I am extra-sensitive about (having screwed it up myself in the past)
@alexmiller: that seems to mean I can't actually change the current getMethods
as it would return stuff older versions can't handle
no, you can change it
but the existing arity needs to continue working like it did
but if it starts returning an extra method that the caller does not expect (with a mismatch between requested arity and actual arity)
true, might need to be a new method then
the old method is then deprecated but continues to work
this is why we screen patches :)
I also have to have a think about the case when two or more methods are returned from getMethods
, I'm not even convinced it will be possible to resolve in a good way tbh
I would greatly prefer an error to ambiguity / arbitrary decision
I guess my concern is that something that would previously resolve without error now has to be an error
that's definitely the kind of thing that should be well-documented in the ticket
but not necessarily a deal-breaker
so what happens in the case of calling a java vararg (1 fixed, 1 vararg) with more than 2 params
do all args >1 get put into the vararg array?
i currently limited the patch to allowing the varargs argument to be omitted, nothing else
and alternately what happens if you invoke that with an arg and a seq - does the seq go in the vararg as the first element or does it become the vararg part?
well, I don't think it's well-prescribed (yet). these alternatives should be mentioned in the description
and we should make choices
and prepare for Rich to overrule them :)
@ragge: not sure if this is relevant at all with what you're doing, but be aware that c.l.Reflector
has some non-deterministic behaviour
unfortunately I don't remember the exact case and don't think I ever logged that in a ticket
you can definitely run into ambiguity finding multiple candidate methods from different ancestors at the same level of the class hierarchy
unless I'm confusing that with protocol matching ambiguities
i was going to start by reminding myself with how varargs actually work in java, and how things like overload ambiguities work there
@alexmiller: yes, the issue is that in the case of protocol that ambiguity is documented, in the case of reflection it is not. even worse, most of the time it throws at compile-time, but in a few cases it just emits a reflection warning and picks a random method if more than one matches at runtime
yeah, that bugs me too
if it were actually picked according to some ordering criteria, that would be slightly better
well... then :)
"first" is the problem there
there might be a ticket for this, don't know. I vaguely recall talking to Rich about it a long long time ago.
@alexmiller added a brief survey of varargs in java and possible clojure options, if we want to explore more than omitting varargs
I will take a look when I have a chance
I just do a timeslice every day :)
wow, I didn't realise void bar(String... x)
and void bar(String x, String... y)
are valid in java
languages are fun :)
ragge: I was looking at this earlier -- the multi-match case is unfortunate. I wonder if allowing the omission of varargs only when it's unambiguous is sufficient
@ghadi: yeah, possibly. if the scope is limited to omission only, that would simplify things. otoh, I'm almost starting to think the current way (forcing arrays) is actually clearer. void bar(String... x)
is really just void bar(String[] x)
, except the java calling syntax... afaict
Good point, thanks. I think it'd be good to get some feedback on the desired scope of the ticket before proceeding too much. Just aim for omitting args, or try to match what you can do in Java closer?
I think it would definitely be trickier, and doesn't seem to be what the ticket was originally about.
However, if the goal is really to reduce "source of confusion when doing interop" with regards to varargs, I think dropping varargs is probably not the only case
if we're scope.creepin()
, it is worthwhile to see whether some of the arguments invocations would change semantics / break code
to be clear, I'm asking for the scope creep at least in terms of consideration
yep, or even work at all... that's why I'm sort of wondering if that direction is worth pursuing at all.
it's just never been worked on, so let's do that
but if there's some indication it's worth exploring at a "can it be done" level, I'm happy to continue down that path
I'd say anything in that table that is a match for what works now should be assumed still valid
it might be useful to annotate those somehow (bold them or comments)
there's an old ticket with a huge patch doing some heavy refactoring on Reflector.java and the reflect/method matching logic in Compiler.java
if this works turns out to be in scope for 1.9, might be worth looking into that one aswell
to be clear, this is me trying to get something in shape that it could be considered
although I see from an older comment of mine that that issue might not be an issue anymore
some of those look like they were split out into CLJ-666 (hrm) and CLJ-792
I've spent enough time in Reflector that I'm sure there is room for refactoring improvement :)
unfortunately I think that any change to Reflector/method matching methods in Compiler will cause some existing code to break
agreed to both parts of that
so I'm going to focus on the visible thing that comes up pretty regularly here which is the varargs stuff