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

Using timezone: Greenwich Mean Time
<arjanb>mlsub.typing.TopKind seems to be missing in cvs02:33
* arjanb leaves02:54
* bonniot joins09:31
* arjanb joins12:30
mlsub.typing.TopKind is missing in cvs
<bonniot>oops, i will check that12:57
what happened to you yesterday?
TopKind is an inner class in TopMonotype12:59
which is missing...
oh no, it's happening again! :-/13:05
<arjanb>ok it compiles again13:14
trying to store the nicedoc string now13:15
it can be turned on be setting a boolean to true in Loader.java
<bonniot>it's good that comments are still handled at the lexer level13:45
i thought they would need to be parsed, and that's what made me wonder about performance
of course the boolean would need to be set by the loading API, but that's a different task13:46
<arjanb>yes but i don't know how you want to make the interface for nicedoc13:47
only the doc comment as file header isn't stored yet13:49
<bonniot>no problem
they are for what? classes, method declarations and fields?13:52
<arjanb>comments before all toplevel definition and methods, fields inside classes can be stored now13:54
did you add the empty line in NiceClass on purpose?13:57
<arjanb>but the comment at the start of the file describing the file can't be stored yet
not really13:58
i first putted docstring in niceclass.field instead of niceclass.newfield13:59
<bonniot>the file comments are not urgent. this is enough to support the nicedoc prototype14:03
thanks for implementing this
i can look at modifying the API to use it, if you wish14:04
<bonniot>what about native "non-null" ?14:05
<arjanb>not sure14:08
<arjanb>maybe after the weekend14:11
<bonniot>ah, you are busy? i thought you were not sure about doing it at all14:12
i think that with the new typing of Object, there is an opportunity to reduce the number of retypings14:13
so it is needed to look over them again, to see which ones are not needed
if we implement something like native "..." we gain more opportunities to remove more14:14
the modes themselves could be decided by looking at what modes happen most often
the interest of doing it by class it that you can open the JavaDoc of the class, look at all the methods, and decide which mode applies best14:15
what is the problem with that?
<arjanb>i think the retypings in nice.lang for java.* should work indepedantly of options used to compile14:17
<bonniot>i agree with that. that's the case if you specify a retyping14:18
we can say that when a class has a retyping mode, that is used over the compilation option14:19
no problem :-)
<arjanb>i'm not sure about increasing the possible combinations of how the types of java methods are determined14:22
<bonniot>i would agree to remove --strict, then14:23
retypings are needed, because that's the most precise you can do. native "..." is a good way to avoid needing millions of retypings14:25
do you agre with that?14:26
<arjanb>--strict is rarely used i think14:34
i agree it's better if we don't need to rely on command line options that change the behaviour of the retypings
<arjanb>i don't know what kind of difficulties users have with using java libs now14:35
<bonniot>Object was one
they also had problems with nullness before the easier default retyping was in place14:36
the goal is to keep this ease, while making it more easy to retype to get more nullness safety when using libs
having less explicit retypings would also help speeding up the compiler and the testsuite14:37
<arjanb>for that i see more in lazily loaded retypings14:38
<bonniot>that can help too, but does not make retyping easier
it's not the main reason to do native "", but it's a nice side-effect :-)14:39
(note that if you load retypings lazily, you loose the option to detect the retyping does not exist and issue a warning, so we need to provide a way to still check them)14:44
<arjanb>so only lazy loading of retypings in .nicei14:46
<bonniot>yes, it seems the best option
but that's only an optimization14:47
<bonniot>so what do you think about adding native "" and then removing --strict?14:48
<arjanb>maybe and i don't think it's urgent14:51
<bonniot>so what do you think is urgent? :-)
<arjanb>really urgent nothing but properties and custom constructor are bigger improvements for the users14:54
<bonniot>i agree
they are also bigger projects :-)14:55
i think it might be better to work on properties first, because we have a clear idea of what they should be, at least in a first step (with the testcases)14:56
do you feel like working on them?14:58
<arjanb>hmm, i would try custom constructors earlier15:01
<arjanb>clearer semantics and it doesn't affect as much places in the compiler15:04
<bonniot>i don't mind :-)
(i hope that the semantics of properties is clear too...)15:05
do you agree with http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/CustomConstructors ?15:07
*away for an hour*15:12
<bonniot>there is a pb with the syntax15:52
class Point { double x; double y; }
Point(double angle, double distance)
{ ... }
this will be parsed as a method implementation15:53
maybe we could say:
new Point(double angle, double distance) { ... }
(at toplevel)
which also makes it clear that we are defining a new constructor15:54
another thing I am not sure about is the call to the constructor15:55
in the proposal, it looks like a normal new expression, while it is treated specially
it might be more clear to use 'this(x: ...)'15:56
here is a complete testcase using this syntax:
// PASS15:57
var p = new Point(angle: 0, distance: 1);
assert abs(p.x - 1) < 0.01 && abs(p.y) < 0.01;
p = new ColoredPoint(angle: 0, distance: 1, color: "red");
assert abs(p.x - 1) < 0.01 && abs(p.y) < 0.01;
/// Toplevel
class Point { double x; double y; }
new Point(double angle, double distance)
{ this(x: distance * cos(angle), y: distance * sin(angle)); }
class ColoredPoint extends Point { String color; }
i thought of using 'new' before a custom constructor too16:10
<arjanb>and i agree with using this(..) for the constructor call inside16:11
i will commit the testcase
<arjanb>the only implementation thing i don't know how that could be done is the call to another custom constructor in a superclass
<bonniot>we don't want that16:16
<arjanb>wdym then in the last two lines of the wiki page?16:17
<bonniot>it's a call to the constructor of the same class, which is derived from a custom constructor of the subclass by adding the fields of the subclass16:19
this is already implemented, when the superclass is a Java class, and has several constructors
there is a default constructor for each constructor of the superclass
it should be possible to reuse the code that implements that to also support this feature in pure Nice16:20
but it's fine if you don't do it in a first step
that makes the code a bit complex, though, that and generic classes16:22
i have to go16:23
<bonniot>good luck! :-)
* bonniot leaves16:24
* bonniot joins21:13
<bonniot>did you start looking at constructors?21:26
<arjanb>the parser part is easy21:35
i'm not sure whether to subclass constructor or methoddeclaration21:38
<bonniot>yes, that's not obvious21:45
my intuition would rather go to constructor, but that's not sure
it might also be the best to have a abstract parent class Constructor, with two subclasses: DefaultConstructor and CustomConstructor21:46
<arjanb>i will try the last option first21:47
<bonniot>another person answer the nicedoc offer :-)23:00
<bonniot>I'll have to find him another job...23:03
<arjanb>why haven't you removed or changed that request for help?23:04
<bonniot>because it's supposed to disappear automatically
but i don't mind new people answering, i just need to explain they can help in other ways23:05
do you have specific ideas to propose to new volunteers?
<arjanb>not really23:07
in the list for help wanted i see things till 3 months old23:09
<bonniot>sounds like a bug23:13
<arjanb>maybe is the documentation outdated23:14
<bonniot>that's also a bug :-)23:33

Generated by Sualtam