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

Using timezone: Central European Time
* arjanb joins18:50
* CIA-3 leaves19:29
* CIA-7 joins
* CIA-7 leaves19:30
* CIA-3 joins
* bonniot joins20:03
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): 22:18
Handle creation of arrays with a parameterized type component (which was broken
by the new handling of type variables in 0.9.8).
<arjanb>no news from me, i haven't done any coding last days22:36
<bonniot>what about the transition to Nice implementation? it should be easier since the changes in the bootstrap method22:51
<arjanb>well i could start with that22:54
should i make a .nice file for every class or some grouping of similar?22:56
doing methods first is not convenient because of all the "notnull"s needed at fieldaccesses23:05
<arjanb>do you have any problems with a gradual transition?
<bonniot>no pb!23:09
not sure about the grouping. we can see after there is some code written, that's easy to change23:10
<arjanb>right, though cvs doesn't maintain history with file renames23:13
<bonniot>yes. i thought making the decision before the first commit23:27
<arjanb>what to do with the mix of constructors and make... for use in the parser23:33
<bonniot>i think make are used when a new object is not created in all cases23:51
of course once we have overloaded constructors, the distinction could disappear, but not yet
<arjanb>i think i will do all make... for now23:53
first little problem: how to translate ContinueStmt.java:40?00:04
non static inner classes are ugly imho00:07
hmm i don't see any way to write that in Nice00:13
<bonniot>why write a make method if the automatic constructor is OK?00:27
<arjanb>most classes have more fields than the parser needs to provide so i would need a custum constructor otherwise00:29
<bonniot>not if the fields have a default value00:30
(you would need to provide it in the make method anyway)
new ContinueExp(loop.code)00:31
<arjanb>the type of ?Expression analyse(?Expression, Info) is not precise00:56
<arjanb>it can only return null if the argument is null i think01:00
<bonniot>that could be expressed by a polymorphic type
<arjanb>hmm that's tricky01:05
does the null case happen anyway?
<bonniot>i don't know01:08
why tricky?
<E | E <: ?Expression> E analyse(E, Info);
maybe that's too precise ;-)01:09
<arjanb>that doesn't work because it can return a different type of expression
then overloaded versions would work01:10
<arjanb>hmm writing <E, E1, E2 | E <: ?Expression, E <: E1, E <: E2> E1 analyse(E2, Info) gives a compiler exception
that's an equivalent type btw, i think
because if you take E1=E2=E, you don't make the type greater01:14
<arjanb>i'm still confused about constraints sometimes01:15
is that a known bug?01:16
i'm wondering how to type that instead of using overloading01:18
<bonniot>yes, at this point in typing you need to stop and think sometimes ;-)01:20
i don't think it's a known bug, you should report it :-)
it would be possible to type as:01:21
<n | n <: ?> n<Expression> analyse(n<Expression>, Info);
but that won't be accepted at the moment01:22
the overriding would not be a bad solution...01:23
what about <nullness n> n<Expression> analyse(n<Expression>, Info); as syntax for such a feature?01:28
<bonniot>not sure about the keyword01:32
<? n> would be consistent, because it means the same as <n | n <: ?>
<arjanb>that would be confusing <? T> <?T> <!T> 01:34
<arjanb>before i forget frank found some oddities in overriding some StringTokenizer methods01:37
class STSub extends StringTokenizer {}01:38
hasMoreElements(STSub this) {
return true;
No method called hasMoreElements is compatible with these patterns
this happens only with StringTokenizer methods that are declared in Enumeration too01:39
<bonniot>normal, Enumeration is a parameterized class01:40
<arjanb>but in java.nice is StringTokenizer made not a subclass of Enumeration01:42
<bonniot>then those methods should be explicitely retyped01:43
<arjanb>i see
<bonniot>now they are ignored because they found in the parent class
<arjanb>could you reproduce that compiler exception?01:59
i have problems creating a testcase02:00
<bonniot>no, the obvious testcase does not give any bug02:06
you should work by dichotomy starting from your error
<arjanb>that is a lot of work in this case02:08
<bonniot>no, since with dichotomy time is logarithmic of the size :-)02:18
<arjanb>not true because you need to keep it compile till the same exception each step02:22
<bonniot>i don't understand02:25
<arjanb>well my experience with niceswing was that the time it costs is proportional to the size02:34
<bonniot>but bossa.syntax is not that long to compile02:36
<arjanb>maybe i will try tomorrow02:37
good night02:39
* arjanb leaves