Log of the #nice channel on irc.freenode.net

Using timezone: Greenwich Mean Time
* arjanb leaves01:16
* arjanb joins04:40
* bonniot joins11:28
hi11:31
it's a bit tricky when the custom constructor has the same signature as a default one...13:56
<arjanb>hi14:29
you mean the same bytecode signature?14:31
<bonniot>yes14:33
<arjanb>giving an error is the easy solution for now
maybe it's possible to do some argument reordening14:34
<bonniot>but that's our testcase... :-)
i think the only solution is to add dummy parameters
which is something you need to do in java too
i suppose it is most important to make sure that the default constructor has the expected signature14:37
or is it not?
<arjanb>yes
it should be usable from java too14:38
<bonniot>which one?14:39
<arjanb>the custom one i think14:41
<bonniot>there could also be several custom ones with same signature14:42
<arjanb>maybe only allowing a one custom constructor with the same signature as a default one if the default is private
<bonniot>there can be several with the same sig, which is different from the default...14:44
<arjanb>or make the default always private in that case and add a dummy param to it
<bonniot>the problem is not with the default one
not in particular
<arjanb>multiple custom constructors with the same signature should not be allowed i think14:45
<bonniot>why not?14:47
<arjanb>either you don't use default argument right or you have the fallback on overloaded constructors
<bonniot>no: (x,y) and (angle,distance) have same signature, but you cannot use default arguments14:48
that restriction would be arbitrary: it's just a limitation of the JVM
we don't need to expose it to people writting pure Nice programs
it's the same for methods at the moment14:49
i agree custom arguments could be more important than the default one, so I will just leave the java signature unspecified for now14:55
<arjanb>well than just add a dummy parameter and writers of Nice code targeting java usage should take that in consideration14:56
a nicec option --targetjava could be added later to generate warnings in such cases14:58
using new(...) as alternative for this(...) in CC is suggested on the wiki15:05
<bonniot>what do you think?15:11
<arjanb>it's a option15:12
<bonniot>which one do you prefer?15:13
<arjanb>not sure, 'this' is used in java but since custom constructor are outside classes does 'new' make sense too15:15
<bonniot>we can see what Brian says15:17
<arjanb>btw for error reporting it would be good to recognize the constructor call in CC at AST construction time15:18
<bonniot>does it matter at which stage it is discovered?15:25
<arjanb>for example when a constructor call is at another place than at the end of the CC body15:30
that's at analyzing i think15:31
<bonniot>it can be reported when it is needed to find it15:34
i have a version of CC basically working15:45
testing at the moment
it probably needs some more work for multi-package compilations, and generic classes
* raist_ joins16:35
hi16:36
<bonniot>hi16:37
arjan, i commited my implementation. could you test it? it would be interesting to have multi-package testcases (I expect some will break)16:50
<arjanb>ofcourse16:51
<bonniot>raist_: can we help you?16:52
<raist_>yeup17:01
sorry
i was away
maybe
i'm programming a plugin in eclipse17:02
and i have looked in google and found a reference to here
you know something about a error : Unhandled exception caught in event loop17:03
and why does it happen?
bonniot, ?17:04
<arjanb>hi
i'm afraid we can't help you with that17:05
<raist_>ok
thank you anyway
;-)
* raist_ leaves
<arjanb>why a the dummy parameter is added when there is no conflict?18:14
i couldn't find other bugs18:55
and multipackage doesn't work at all
daniel?19:35
<bonniot>i'm back20:29
could you commit testcases for packages?
<arjanb>yes20:30
but what is the reason of always a dummy parameter?20:31
<bonniot>at the moment, i need the default constructor to always havethe expected signature
to will probably not be needed anymore when packages are handled20:32
<arjanb>i see
what should happen with custom constructor declared in another package than the class20:48
<bonniot>no problem, since we can regenerate the class20:52
<arjanb>ok, testcases committed20:54
<bonniot>thanks21:42
isn't the last test redundant?
<arjanb>no that one gives a different error21:44
<bonniot>ok21:46
i'm getting annoyed at the testsuite being so long to run21:47
couldn't you look at the retypings, to see how we could remove many, maybe with the nullness specifiers for classes21:48
<arjanb>about half of the retypings are nullness only21:53
well i can try to find some smarter guessing rules
<bonniot>wouldn't the class specifiers allow to remove most of the retypings for nullness?21:54
<arjanb>probably21:58
<bonniot>implementing them should not be very hard, so if they can handle many retypings, it would be worth it21:59
i can make the first test pass, but it is not calling the right constructor22:12
so i'm working on loading the custom constructors from the bytecode instead, so it is obvious what their signature is22:13
it's also better, because it means less text parsing :-)
do you know if the parser could easily be made reentrant?23:16
<arjanb>reentrant?
almost all method and fields are static in the parser23:22
<bonniot>yes, but javacc could have an option to generate a non-static parser23:25
<arjanb>that option exist23:29
<bonniot>how does it work?23:30
<arjanb>just add -STATIC=false on the command line before the input file23:32
but why does this matter?23:35
it's easier to add STATIC = false; to the option block in Parser.jj23:38
<bonniot>if we put CC in bytecode instead of in package.nicei, it is practical to be able to call the parser on small bits of syntax to get high-level information, like the formal parameters23:39
naturally, this happens in the middle of parsing a file, so you cannot do it if the parser is static
<arjanb>so you want to remove package.nicei over time?23:45
<bonniot>i think so23:46
it's more hig-level and robust to use the bytecode
it should be more efficient too
what do you think?23:47
<arjanb>bytecode allows the use of new attributes so why not use that23:49
<bonniot>Passed :-)23:52
all three cases...23:55
the 'new C(...);' was only for parsing package.nicei, right?23:58
<arjanb>yes
<bonniot>one annoying point is that I have to pas around a reference to the list of definitions, so that when creating a NiceClass the list of constructors found in the bytecode can be added to the list00:02
hum, maybe it could be found in the package00:03
<arjanb>i just implemented user defined fields for enums00:04
<bonniot>i see, you were working secretely? ;-)00:05
<arjanb>i found an oddity with the Object type00:09
List<String> list = new ArrayList();
Object x = 5;
int y = 5;
list.contains(x);
list.contains(y);
<E,T | E <: T> boolean contains(java.util.Collection<E>, T) =00:10
native
the first call to contains typechecks and the second one not
<bonniot>yes, because String <: Object, but not String <: int00:12
why is that surprising?00:14
<arjanb> List<long> list = new ArrayList();00:16
int x = 3;
list.contains(x);
wrong example
class A {}00:18
class B extends A {}
class C extends A {}
List<B> list = new ArrayList();
let x = new C();
list.contains(x);
in this case is x downcasted to A00:21
while in the first case int is not downcasted to Object
<bonniot>the difference is that B and C has a common super-class (A), while int and String are incomparable00:25
<arjanb>so the Object type is quite strange00:27
not the common super type of everything but everything is a sub type of Object00:28
what's the reason of making final fields not final in bytecode?00:32
<bonniot>we don't want a common super-type for everything, or the compiler would not catch "A" == 3
<arjanb>i agree
<bonniot>i'm not aware of that, the implementation might just be missing00:33
<arjanb> List<String> list = new ArrayList();
Object x = 5;
list.contains(x);
i didn't expected that this would typecheck
<bonniot>that's because you defined00:38
<E,T | E <: T> boolean contains(java.util.Collection<E>, T)00:39
with
<T> boolean contains(java.util.Collection<T>, T)
it would not typecheck
<arjanb>but the A B C class case should typecheck00:40
<bonniot>the Object case is useful too, because you can do00:43
Object x = "ABC";
so the list might indeed contain the object
<arjanb>right
are you changing things in NiceClass.java?01:13
* ChanServ leaves01:15
* ChanServ joins01:21
<bonniot>why?01:23
<arjanb> method.fieldDecl.setFlag(isFinal, gnu.expr.Declaration.IS_CONSTANT);01:25
was missing in createField()
<bonniot>ok
wich CVS, there is no problem in several people working on the same file...01:26
can you write a testcase for the final attribute? it should be doable with reflexion02:00
i think i have the multi-package CCs working02:01
<arjanb>a testcase for that?02:05
good night02:09
* arjanb leaves02:10
* bonniot leaves02:11