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

Using timezone: Central European Time
* arjanb leaves03:11
* CIA-3 leaves09:15
* CIA-3 joins
* CIA-3 leaves09:21
* CIA-3 joins
* CIA-3 leaves09:22
* CIA-3 joins
* CIA-3 leaves
* CIA-7 joins09:23
* CIA-7 leaves09:31
* CIA-7 joins
* bonniot joins11:28
* arjanb joins13:10
* ChanServ leaves13:56
* ChanServ joins14:03
<CIA-7>03arjanb * 10Nice/src/ (5 files in 2 dirs): Removed usage of old pattern syntax.
03arjanb * 10Nice/stdlib/nice/ (6 files in 2 dirs): Removed usage of old pattern syntax.14:27
03bonniot * 10Nice/debian/watch: Added upstream watch file for Debian.14:37
<bonniot>hello arjan14:39
<arjanb>hmm what should i do next?14:46
<bonniot>i think one the main aspect to get before 1.0 is visibility15:00
still don't like it?15:16
<bonniot>why not?
<arjanb>i prefer doing things i know how to do it or having a clear goal in my mind15:23
<bonniot>what's not clear about visibility?15:24
<arjanb>it's clear but i'm indifferent to visibility15:28
<bonniot>i see15:30
it's important to have it, though
especially for larger projects, but even if we need to have internal utility functions in the libraries15:31
<arjanb>to me visibility is more an advice to the user of the code than something that an compiler should enforce15:32
<bonniot>it's good that the compiler enforces it, because it allows you to reason about invariants of your code
you can be sure that certain code will never be called directly by clients of the package15:33
<arjanb>true, it could be usefull for libraries distributed without source15:43
<bonniot>i remember you told me before about the Class<T> feature16:22
do you have specific ideas about it?
<arjanb>i only know that java 1.5 gives Class a type param16:47
do you see any problems with Class<T>?16:53
<bonniot>it's implemented now, so i think it will work16:58
one thing i had to do was to allow Class without type parameter
it would break many things no to do that, and when you do reflexion it is often impossible to know in advance the type16:59
<arjanb>reflexion functions could return a polymorphic Class<T>17:00
<bonniot>yes, but you need to declare the type of local variables or method arguments17:01
<arjanb>i see17:02
<bonniot>so i introduced the notion of "unknown type"17:03
you can write Class, and it's understood the type parameter is not known
<arjanb>couldn't polymorphic local variables solve a part of the problem?17:04
<bonniot>if you don't want to declare the type of locals, yes17:05
but it's still needed to have this unknown type I think17:09
<arjanb>would Class<+T> make sense?17:10
<bonniot>i thought about it17:15
Class<T> says: when calling newInstance, you will get an instance of type T17:16
Class<+T> says: when calling newInstance, you will get an instance of type T or a subtype
so the former gives a more precise information, and that can be useful
one motivation was to be able to write this method:17:17
@param source an object of type T
@param target the Class of type U, a supertype of T
@return a new instance of class U, keeping all relevant fields
from object <code>source</code>
<T, U | T <: U>
U demote(T source, Class<U> target)17:18
// Create the new object
U res = target.newInstance();
// Initialize all fields of the new object by copy from the source
for (field : target.getFields())
field[res] = field[source];
return res;
if Class was covariant, you wouldn't be sure that you are really doing a demotion
<arjanb>i see17:19
<bonniot>another thing is the implicit this in method calls18:08
<arjanb>*away for meal*18:14
* CIA-7 leaves20:12
* CIA-6 joins20:13
03bonniot * 10Nice/ (2 files in 2 dirs): 20:21
Properly release cloned types when resolving overloading with overlapping
Java methods.
<bonniot>good night23:55
* bonniot leaves
* CIA-6 leaves00:37
* CIA-6 joins00:40