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

Using timezone: Central European Time
* RicoShit joins06:40
Hello everybody
Anybody home?06:41
* RicoShit leaves
* zzorn joins07:13
* bonniot joins13:22
* gamsl joins15:49
hi daniel
<bonniot>hi!15:50
how are you doing?
<gamsl>i'm sorry i didn't react for so long, i had a little university project to finish and was away skiing during christmas holidays
i#m fine thanks, you?15:51
<bonniot>i'm well. i see you are always up for fun ;-)15:52
<gamsl>yep :-)
guess what
morocco is waiting again for me also :-)
<bonniot>when?15:53
<gamsl>february .... but maybe along with my laptop ...
<bonniot>;-)
<gamsl>how is your phd doing=?15:54
<bonniot>OK. I hope to have the written part done in a couple of weeks15:55
<gamsl>nice :-) what's still missing then?15:56
<bonniot>it's only details, but that's time consuming15:57
<gamsl>i can imagine .....15:58
i have a few questions concerning nice ...
<bonniot>yep
<gamsl>i'm experiencing a few problems, type inference with let for example, it seems either i do something wrong, or nice doesn't infer option types right16:00
if i write
let ?IVMRunner runner = vm.getVMRunner(mode);
then everything works fine16:01
there is no retyping vo getVMRunner (a java method) so it correctly returns ?IVMRunner
however
let runner = vm.getVMRunner()
if(runner == null) ....16:02
tells me that i try to compare a non null value with a null value
<bonniot>that's a warning
<gamsl>yes, but runner may be null16:03
<bonniot>default retypings have been changed to be less strict
so now Java methods return non-null by default, unless specified by an explicit retyping16:04
<gamsl>aa i see
but parameters are still assumed to be ?Type ?
<bonniot>it's always a compromise, but this seems the less restrictive and be the most common situation16:05
yes
<gamsl>ok, and if i write let ?IVMRunner runner = vm.getVMRunner(mode); i'm basically overriding the default behaviour on the fly?
<bonniot>that's a way to look at it ;-)16:07
<gamsl>hehe
ok next question:16:08
is there a pattern for initialization of instance variables (there is no useful default value, but null as default value would be ugly by design)16:09
i don't like cast(null) it looks pure evil
<bonniot>then how do you know their value?16:11
a computation?
<gamsl>in the example i encountered, they would be initialzed by some init(..) method automatically called by superclasses ...16:12
now the problem is if there is no default value for them, they need to be given in the constructor16:13
which is not possible as superclasses handle initialization with init
<bonniot>what about a custom constructor?16:14
<gamsl>i dont know how this would solve the redirected initialization with init (as init is called by superclass)
<bonniot>is the superclass a Java class?16:15
<gamsl>yes ... eclipse class
<bonniot>then it's a design problem of the superclass16:17
it just cannot guarantee that the fields are initialized before they are used16:18
<gamsl>in general fields that won't be initialized with a typical initialization method (like autoconstructor, custom constructor, init), but at some point later in time, have the problem, that if they dont contain null by design, they are hard (impossible?) to declare as no useful default value exists, until one is assigned .. without cast(null)
cast(null) solves everything .. but just looks so evil ...
.-)
<bonniot>yes, it's because your design makes you do something unsafe16:19
<gamsl>i see the point
there is no way to prevent access before the field is initialzed properly16:20
on the other hand, i see a lot of situations, where the correct initialization at construction time is simply not possible16:21
* arjanb joins16:22
<bonniot>those situations might be avoided by a design change
<arjanb>hello16:23
<gamsl>hi arjan
<bonniot>hi16:24
<gamsl>do you think everything could be handled at construction time? i dont think so16:25
<bonniot>typically, the design change would be to use short-lived, immutable objects instead of long-lived, mutable ones16:26
<gamsl>like localvars instead of fields?
<bonniot>possibly. or creating new objects instead of updating existing ones (functional style)
<gamsl>i don't have any experience at all in programming functional style16:27
<bonniot>you can also keep the same design, you just need to use cast(null), which reminds you that it is potentially unsafe. In java it would be as unsafe, just implicitely16:29
<gamsl>my problem with cast(null) is more a personal issue i think :-) it's just the real opposite to everything nice wants to achieve16:31
to me
back in 5 minutes ....
<arjanb>daniel: the problem of throwing exceptions in the parser seems to be fixed in javacc cvs but no new release yet16:34
<bonniot>cool
i don't think it's urgent, we could wait for a new release16:35
gamsl: if you algorithm is unsafe, there is nothing Nice can do for you ... except warn you that it is unsafe, by forcing you to use a cast
then it's up to you to either make sure it's actually not going to fail (as long as you don't change anything), or try to find a different design16:37
<gamsl>ok, i will see to avoid cast(null) as often as possible17:00
or keep it private whenever possible, sucht that at least external clients cant access it17:03
btw is there a way to test a variable that was initialized with cast(null) if it is still not initialized ... nullness tests will fail since the variable was declared to not contain null17:04
<bonniot>no, nullness test should work17:06
<gamsl>but a warning will be emitted right?17:07
<bonniot>yes
<gamsl>ok enough for that ... another question related to option types: 17:08
in java it's common to set variables to null for garbagecollection purposes, how can i mark notnull objects to be ready for garbage collection?17:09
(this happens quite often in eclipse)17:10
<arjanb>it doesn't make much sense for local variables17:11
<gamsl>true17:12
i guess this actually really isn't a big issue, as fields that should be garbagecollected justify a declaration with null as possible value17:15
<arjanb>right17:16
<gamsl>then what about final parameters?
is this possible?
<arjanb>in methods, no17:17
<gamsl>would it be desirable? and where are they possible, if not in methods?17:18
<arjanb>what reason are they used for?17:20
<gamsl>i guess it's a performance issue in java
<arjanb>the difference doesn't exist in bytecode17:22
<gamsl>ok17:23
anyway, wouldn't final parameters make sense?17:24
<arjanb>i did make them final by default once but that can be ackward17:25
<gamsl>why not make a new syntax?17:26
<arjanb>i think it's too much noise for little use17:28
<gamsl>maybe, i don't really know how common it is ....17:29
<arjanb>i have only seen final parameters in code where it was the standard to have all parameters final..17:30
<gamsl>there is an issue with inner classes (i think only anonymous ones), they are only allowed to have final parameters17:31
i don't know why this is necessary, anyway nice knows no inner classes
<arjanb>that has a historic reason17:32
see quote at http://article.gmane.org/gmane.comp.lang.lightweight/227417:35
<gamsl>thx
interesting17:40
one feature that really would be nice to have, would be to be able to explicitly import single classes from packages. This could really increase expressiveness i think!17:43
<arjanb>yes importing and qualified names need some work17:46
<gamsl>could this become a priority?
<arjanb>not for me doing that..17:51
<gamsl>is it a lot of work?17:52
<arjanb>i'm not sure, i'm not comfortable with that part of the code17:54
<gamsl>ok17:55
i just think importing single classes is very good documentation for a source code file17:56
<arjanb>yes though it's not clear what it would mean for nice classes
<gamsl>why? because method implementations can be in different packages?17:57
<arjanb>yes17:58
<gamsl>i think the declaration is what matters
and that's in one exact package/class17:59
<arjanb>no they can be in other packages too
<gamsl>the same method be declared in different packages?18:00
does it have something to do with override?18:01
<arjanb>not the same methods but methods with the same class as first argument
<gamsl>i don't see any difference in importing a.*; and a.A, cant it just be syntactic sugar for .* imports?18:02
with .* performed in the background18:03
<arjanb>that would work for documentation purposes but it doesn't reduce ambiguities18:05
<gamsl>ok ... i didn't notice ambiguity issues so far18:06
what are the problems?18:10
<arjanb>having a class with the same name in the imported packages18:13
<gamsl>you mean class a.A import b.A ?
<arjanb>yes18:14
*away for dinner18:18
* zzorn joins18:27
<arjanb>it looks like catching checked exceptions in java isn't possible without the throws clause19:11
i think that's a bug in java spec considering other languages for the jvm19:14
<gamsl>btw is there a reason for nice not having a throws clause? isn#t it good documentation as well? (although sometimes it's tedious to write all thrown exceptions down ...)19:16
<arjanb>throws clause don't combine well with first class functions19:18
and checked exception are considered a bad idea now
<gamsl>?
<arjanb>http://www.mindview.net/Etc/Discussions/CheckedExceptions19:20
<gamsl>i cannot connect to the site because of proxy error ...19:21
but speaking of exceptions:
using "throw" to prove a variable doesn't contain the null value only works if "throw" is in the same method, however if it is in a convenience method, whose single statement is the "throw" the prove doesn't work.19:22
<arjanb>why not using assert instead?19:25
i had some thoughts about using postconditions the signal such non local properties19:27
<gamsl>assert works but in that situation seems to be only a workaround19:29
<arjanb>can you give an example?19:30
<gamsl>package exceptions;
class A {}
class Ex extends Exception {}
void foo()
{
let ?A a = new A();
if(a == null) throw new Ex();
A aa = a;
}
void abort() = throw new Ex();
void bar()
{
let ?A a = new A();
if(a == null) abort();
A aa = a;
}
bar fails in the last line
<arjanb>if you don't need to throw a specific exception i would use assert19:32
i think some way to make nicec understand a method doesn't return would be usefull19:33
<gamsl>i just encountered that situation in eclipse, they often encapsulate error messages, status codes etc for exception object creation into a method (which is a good idea i think)
<arjanb>void abort() ensures false { ... } could be a solution19:35
<gamsl>i can't follow you19:36
<arjanb>ensures false always fails so nicec could understand that method won't return19:41
<gamsl>ok i'll try that ... is it possible to add DBC constraints to (overriden) java methods=?19:42
<arjanb>ensures false doesn't work yet it's only an idea19:43
<gamsl>i just noticed .-)
<arjanb>overriding and DBC don't work together atm19:44
<gamsl>is it planned?
<arjanb>yes but only for postconditions19:46
<gamsl>ok .. i suppose there are good reasons why not for preconditions as well. so is it not possible to add DBC constraints to java methods? (without override)19:47
<arjanb>not atm but maybe it could be implemented using retypings19:49
<gamsl>mhm
btw void abort() ensures false compiles fine. it has no meaning though?19:50
<arjanb>right19:51
<gamsl>one last thing i can think of atm: the warning about an exception in the compiler is inappropriate in some cases (e.g. a missing class on the classpath, shouldn't encourage a user to file a bugreport)19:53
<arjanb>which warning?19:54
<gamsl>an exception occured in the compiler .... (it's not a warning really)19:55
if a jar that contains a class that is used is not found, nicec, under certain circumstances i haven't yet figured out, tells that an exception occured in the compiler, whereas the addition of the missing jar solves the problem19:57
<arjanb>if it happens with the latest version it is bug
<gamsl>i have dev version
<arjanb>nicec should catch all exceptions and report a error or warning19:58
<gamsl>normally nicec displays a warning about missing components on the classpath, but i'm sure i saw the above explained as well19:59
what i find also strange is, that nicec reports a nullpointer exception in imported java code as an exception in the compiler (although it is one i guess). remember, that led me to file a bugreport some time ago, although it was simply a npe in java code.20:00
<arjanb>i don't remember that20:02
<gamsl>i filed the report, showed you the code and you told me that it is a npe in java code which was true.20:04
it was sometime in late november i guess
i deleted the report immediately20:05
<arjanb>that was caused by the eclipse plugin right?20:07
<gamsl>yes20:10
my problem is just that the message is a bit misleading, as it encourages to file a bugreport20:11
<arjanb>every exception in the compiler should be reported because at least something is wrong in error handling/reperting
<gamsl>yes but npe in imported java code is no bug in te compiler20:13
<arjanb>so catch clause are missing where that java code is called20:14
<gamsl>yes but who writes catch(NullPointerException e) { ... }20:16
in java20:17
<arjanb>catch(Expception e) { //something went wrong in external code20:18
<gamsl>since every line of java code is a possible npe, would you encourage to generally call java code in try/catch blocks=?20:19
<arjanb>no but it make sense in this case to do it in nicec20:21
* zzorn leaves20:22
<gamsl>aa ok, so this would be a way to prevent nicec from reporting exceptions in external code as such, and not as a bug in the compiler20:24
<arjanb>yes20:27
<gamsl>i would appreciate that!20:28
<arjanb>could you report it when it happens again?20:31
<gamsl>yes
the article about exceptions is interesting, i guess there won't be a throws clause in nice :-)20:41
<arjanb>maybe there will but only for easing the use of nice from java20:44
on method declarations without having any meaning in nice20:45
daniel: what do of the throw clause? see also http://sourceforge.net/tracker/index.php?func=detail&aid=1107805&group_id=12788&atid=36278820:47
<bonniot>yes, i saw the rfe21:21
one interesting thing is that there was some work on exception inference in ML (with anonymous functions). it was in a separate tool, not in the compiler itself21:22
<arjanb>i'm not sure that would be worth the complexity21:28
allowing throw clauses on method declarations is a simple solution for the using from java problem21:29
<bonniot>yes21:30
<arjanb>i will look into it21:32
there are so many open issues atm that it might be usefull to have a list of things that has been agreed on how to resolve it21:38
<bonniot>you can leave comments in the tracker, and do assignments21:40
<arjanb>sure but that doesn't help in finding in what to do if i have a few hours21:44
<bonniot>why not? what if you assign those to yourself? there is your list21:58
<arjanb>there are a lot more things than on the bug/rfe-tracker22:05
<bonniot>those things could be filed too, no?22:06
<arjanb>maybe, for example most of the bugs in the testsuite aren't in the tracker22:08
<bonniot>no objection to adding them, if it's useful for you ;-)
* Palak joins22:39
sup22:40
<arjanb>hello22:41
<Palak>this is kind of random but dont spose you have extensive experience with maven22:42
<arjanb>i haven't any22:43
<Palak>doh k
* gamsl leaves23:03
* gamsl joins23:10

Generated by Sualtam