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

Using timezone: Central European Time
<arjanb>good night03:26
* arjanb leaves
<bonniot>good night04:24
* bonniot leaves
* bonniot joins09:59
hi10:00
<Bluelive>moin13:37
short night for you ?
<bonniot>hi, yes, kind of short ...13:38
<Bluelive>foreach (i in 1..10) is going to be so much faster then Int i=1; while (i<=10) { ...; i+=1; }13:41
changing int from a primitive into a reference type, and then making them immutable does horrible things 13:42
<bonniot>yes. i got a very nice speedup when i switched to primitive types :-)13:43
<Bluelive>so you use boxing ?
<bonniot>yes13:44
<Bluelive>well i could get a distance with mutable ints, or some way to pool them
i+=1; gets replaced into i:= i+1; which becomes i:=i.operatorAdd(someConstantLiteralInt);13:45
and operatorAdd would even call new
say bye bye to speed
<bonniot>mutable ints would be weird because of aliasing!13:46
<Bluelive>but iterators should be much less common
well immutable and mutable int could be disjoined in the inheretance tree, so you should call some method to get a copy of the correct type to avoid such a problem13:47
* arjanb joins13:48
<Bluelive>hi arjan13:49
<arjanb>hi
<bonniot>hello13:55
<Bluelive>ow this is fun :( class A<T> { void hi(T x); } class B extends A<C> { void hi(C x); }15:30
Yet Another Retyping Stub(c)(r)(tm) to the rescue15:31
<arjanb>how can C be used in B without B having a type param?
<Bluelive>B extends A<T> concreted into A<C>15:32
Where T is parameteric C is concrete
the problem is that its A.hi(Object o) according to the code generator15:35
but b.hi(C o)
altough the override is correct
<arjanb>i don't think so
<Bluelive>not a big problem, just annoyance, because the vtable entry in an instance of B for A.hi(Object) need to cast it to C and call B.hi15:36
<arjanb>you can't override with a more restrictive argument type
<Bluelive>why would the ovverride be incorrect ?
A.hi(T) == A<C>.hi(C) 15:37
the difference is that T is parametric and C is concrete
and because we extends A<C>, B only knows A<C>.hi(C)15:38
<arjanb>hmm this is getting tricky15:41
<Bluelive>yups
* bonniot leaves15:45
* bonniot joins
oop
s
planing to close another window
I'Ll be going
have a good christmas eve!
<Bluelive>the type systems gets it at the moment, but the code generater barfs on the real type of the parameter of the method
<arjanb>nicec doesn't seem to understand it either:
class C {}
class A<T> {}
class B<T | T <: C, C <: T> extends A<T> {}
<!T> void hi(A<T> a, T t);
hi(#A a, t) {}
hi(B a, C t) {}
<Bluelive>bonniot: have a good one :)
<bonniot>(and not too much typing :-)
what is the result in Nice?15:46
<arjanb>Method <!T> nice.lang.void hi(testbug.A<T> a, T t) is not completely covered:
no alternative matches (testbug.B, nice.lang.NiceComparator)
<Bluelive>i think my example is more readable ;p
<bonniot>true, this is an area that still needs some work in Nice15:47
arjan, nicec is correct
you should use A instead of #A15:48
(because you call call hi(a, "") and a is a B at runtime, you need to habdle that case!
handle
<arjanb>but the type param of B can only be class C15:49
<bonniot>right15:50
i thought we already worked on that15:51
is it still an open bug?
you should look at the existing testcase, which I think passes, and see the diffence
i have to go
bye!
<arjanb>bye daniel i will be back on monday
<bonniot>ok
bye bl
* bonniot leaves15:52
<arjanb>right this is a known bug in nice15:53
dat zou wel eens erg lastig kunnen worden als het typesysteem van nice het ook niet snapt15:57
<Bluelive>hmz15:58
mijn type systeem snapt het eigenlijk al
maar vanuit het oogpunt van B zijn alle T's in A door C vervangen, inplaats van strak geconstraint te zijn15:59
<arjanb>je moet iig constraints gebruiken in B16:01
<Bluelive>in alpha niet
als ik {alias A<C> D;} doe
dan is er een class D effectief die er voor iedereen uit ziet als een volledig concrete class16:02
<arjanb>als syntax niet maar in het typesysteem is dat makkelijker
<Bluelive>tsja moest ook twee slagtich typesysteem maken
eentje met alleen concrete types, A<T>, B etc
en eentje met type instances, zoals A<C>16:03
en voor alle instances een vertaling van de concrete geven
aan de hand van de para types
denk dat dat ongeveer de beste combo is tussen c++ templates en parametrics zoals die in nice voor komen16:07
probleem is wel dat voor de velden in a die b niet override er een stub moet worden gemaakt
het geeft wel een paar vraagtekens bij properties, maar dat valt op te lossen door wat slimmer naar methods te mappen16:17
<arjanb>een combinatie van beiden heb ik nog niet eerder gezien16:18
nieuwste post LtU al gezien?16:48
<Bluelive>ff checken16:53
zucht geen eten ;(
capser alweer dicht
<arjanb>en mensa ook dicht?16:54
<Bluelive>je bent m'n held16:55
daar had ik niet aan gedacht
<arjanb>beetje afwezig van de echte wereld? :D16:56
<Bluelive>dat ltu articel, hoe is dat uitgebreider dan wat nice heeft
sjuh
<arjanb>nog geen tijd om te lezen moet spullen pakken en richting ouders16:57
<Bluelive>ah je gaat vanavond
ff printen voor in de trein ?
<arjanb>geen printer en lezen in bus zuigt16:58
<Bluelive>volgend jaar weer terug op #nice ?16:59
<arjanb>maandag al hoop ik17:00
<Bluelive>okiez17:01
<arjanb>4 dagen familie is lang genoeg :)
<Bluelive>ik ben zowieso vanaf overmorgen alweer bewust aanwezig
<arjanb>hmm zelfs 2 post over generics op LtU17:09
cu
* arjanb leaves