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

Using timezone: Central European Time
* bonniot leaves01:24
* arjanb leaves02:54
* lions joins11:31
* lions leaves11:32
* arjanb joins11:54
hmm weer iemand hier op een te vroeg tijdstip12:19
* bonniot joins12:56
hi13:23
<arjanb>hi13:25
<bonniot>arjan, don't we need the Point(...) notation for overloaded constructors?13:26
<arjanb>maybe but we need 2 different notations, one for CC and OC13:28
<bonniot>what was the last proposal?13:30
(you mean for calls or for definition?)13:31
<arjanb>it's not a big issue which notation to use of CC or OC as long they are distinguishable13:33
that article comparing C# with java mentions that C# doesn't allow to exit a finally block and i think that's a good idea13:42
<bonniot>hum, it seems it would be possible to use Point(...) for the nested call, since normal constructor calls are always new Point(...)13:46
the only problem I see is that then you could be tempted to write such call with a different class13:47
so it's redundant information13:48
<arjanb>so we have 3 options now13:49
is it ok to restrict exiting out of a finally clause to you?14:00
<bonniot>does not look like a big problem to me. and it might be restrictive14:08
<arjanb>boolean foo() {14:10
try {
throw new Exception();
} finally {
return true;
}
}
void main(String[] args)
{
println(foo());
<bonniot>prints true
<arjanb>right so the exception just disappears14:11
<bonniot>yes, that's what you asked for14:13
if you don't want that, don't put the return inside finally14:14
but sometimes it can be useful to get this behaviour too (with a conditional return, in particular)
<arjanb>true 14:22
<Bluelive>what do you think of calling the default constructor on notnull variable declarations that dont get initialized ?15:48
<bonniot>sounds sloppy to me15:49
sounds like C++ :-/15:50
<Bluelive>:)
what method does nice use to remove the maybe from a type ?15:51
<arjanb>nice doesn't have instanciation so no need to remove maybe15:55
<bonniot>mabye what you mean is:16:01
?String s = ...;
if (s != null) {
Here s has type String
{
}
<Bluelive>hmz16:03
isnt that a bit spooky ?
<arjanb>why16:05
Collection c = ...
if (c instanceof List) {
<bonniot>it's intuitive
<arjanb> type of c is now List16:06
}
<Bluelive>what does that do to ambiguity when resolving method calls ?
<bonniot>example?16:07
<Bluelive>x(c); which is defined both as x(Collection) and x(List) ?16:08
<arjanb>that would be a badly overloaded method but nice chooses x(List) here16:09
<bonniot>it's orthoginal with the "dynamic type inference" aspect16:15
overloading resolution happens as usual
with the inferred type
<Bluelive>maybe something for the future16:21
been thinking about it, as a way to find faults during compiling i agree, but i find it a dangurous to actually change the type of a variable19:30
although notnullness isnt really part of the type
<bonniot>what do you mean dangerous? we only do type-safe changes19:33
<Bluelive>Well the allowed types for c now inlcude List, altough this is valid, the variable is typed as Collection, not var19:35
if var was an explicit modifier on the variable definition it would be alot clearer for a programmer19:36
im a affraid the compiler assumes to much about the variable, which the coder forgets and syntax errors get overlooked
<bonniot>what does this have to do with "var"?19:39
and could you give an example?
<Bluelive>i thought you were talking about var ?19:40
that c actually can represent a List after the if, thats what a var does ?19:41
<bonniot>c does not have to change
it can as well be that it has a fixed value
and you just test to see if you are in a subcase or not19:42
Collection c = foo()
maybe foo returns a List, maybe not
<Bluelive>yeah i see that, im just not sure that introducing in effect a form of dynamic typing is what i like personally :)19:43
<bonniot>depends what you can dynamic typing
<Bluelive>dynamic typing isnt the right term
<bonniot>yep
actually, it's a kind of static analysis19:44
<Bluelive>well the contract of the variable gets changed implicitly
<bonniot>no19:46
the compiler is just more clever about his knowledge19:47
about the variable
<Bluelive>yeah, but the smartness gets used by the programmer19:48
<bonniot>so where's the problem?
<Bluelive>that even though c has been proved to contain something that can also be a list, that c itself is a container typed as Collection
s/container/variable/19:50
<bonniot>and?
<Bluelive>nothing :)
its samrt
smart
but i think its also dangerous
<bonniot>well, you'll need to justify that19:51
<Bluelive>its just an opinion about implicit stuff in a language
<bonniot>as soon as the compiler is gathering some information, it's "implicit"19:53
the question is whether the rules are intuitive or not
see for instance the analysis of initialized variables, it's very similar19:54
<Bluelive>it probably uses the same code, and for those functions i intend to put it into alpha in the future (stuff like checking if some checks can be dropped and such)19:55
<arjanb>daniel have you heard of the scala language?20:20
http://scala.epfl.ch/index.html20:28
* lodewijk joins20:30
<arjanb>it has many similarities with Nice and is designed by martin odersky (pizza, gj)
hi
<lodewijk>hello
<bonniot>hi20:31
<lodewijk>does the nice runtime do something funny with the class loading mechanism?
<bonniot>yeah, heard about scala
where was it announced?
lodewijk: no, why?
<lodewijk>because this snippet of java works:20:32
import com.sleepycat.db.*;
public class Proef {
public static void main(String[] args) {
System.out.println(new DbException("hallo").toString());
}
}
and runs, but this snippet of nice has the VM not even attempt to touch the db4.2-java.jar:
import com.sleepycat.db.*;
void main(String[] args) {
System.out.println(new DbException("hallo").toString());
}
<bonniot>what happens?20:33
<lodewijk>same classpath, same everything. the .class'es javap -c'ed show approximately the same as well.
Exception in thread "main" java.lang.NoClassDefFoundError: com/sleepycat/db/DbException
at foo.fun.main(~/werk/nice/./foo:2)
<bonniot>is the jar on the classpath?20:34
<lodewijk>bonniot: yes. it is both while compiling and running, both in java and in nice.
<bonniot>if you do 'java -jar', the user classpath is ignored, you know that?
<lodewijk>bonniot: ouch! no I didn't know that.
that's it then.
<bonniot>yes20:35
<arjanb>we should warn users about this
<bonniot>it's becoming a FAQ
yes
nothing to do with Nice, though
<arjanb>daniel: http://lists.xml.org/archives/xml-dev/200401/msg00666.html found via LtU20:36
<lodewijk>how would I do this then? bundle up my code in a jar that references other jars?
<arjanb>or pass the classpath at the command line20:37
<lodewijk>arjanb: but that's what I did: java -cp /usr/share/java/libdb4.2-java.jar -jar proef.jar
<bonniot> java -cp /usr/share/java/libdb4.2-java.jar:proef.jar proef.fun20:39
<lodewijk>okay, so this seems to work: java -cp /usr/share/java/libdb4.2-java.jar:proef.jar foo.fun
<Bluelive>i would really like LtU to have a high noise channel, then i could try to say a few things, when i try to comment it never becames anything sensical or smart20:40
<lodewijk>bonniot: beat me to it by two seconds :)
<bonniot>:-)
there must be a way to package the jars too, tell us if you find out
<lodewijk>will do. I'm off to write more code, thanks for the help :)20:41
* lodewijk leaves
<bonniot>good night23:49
sudo halt23:50
<arjanb>wrong window
good night
<bonniot>yep
:-)
* bonniot leaves

Generated by Sualtam