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

Using timezone: Central European Time
* bonniot leaves04:02
* arjanb joins12:23
* bonniot joins12:25
<bonniot>hello arjan12:41
<arjanb>did i miss something?12:42
i see lodewijk had some problems with static interface fields and assertions12:48
are these solved now or should i look at it?12:53
<bonniot>for static interface fields, yes12:59
it's worked around for him, but we still need to solve him
solve it :-)
<arjanb>i will try13:00
<bonniot>for assertions, it's not really a problem, it's a feature request :-)
and he started working on an implementation
so we can see how he manages, and of course help if he has questions13:01
it wouldn't hurt to have another contributor, as we have lots of interest and feature ideas these days :-)13:02
<arjanb>indeed :-)
the check on JavaClasses.java:336 has no effect as it seems13:07
<bonniot>i think what happens is that there are two different MethodDeclaration that represent the same field13:10
at least that's one possibility
yeah, must be it13:11
WindowConstants.FOO and Bar.FOO are not the same, even if Bar implements WindowConstants
is the field retyped?13:12
<bonniot>what are the class names?
<arjanb>Ambiguity for symbol EXIT_ON_CLOSE. Possibilities are :13:15
nice.lang.int EXIT_ON_CLOSE() = native javax.swing.JFrame.EXIT_ON_CLOSE;
nice.lang.int EXIT_ON_CLOSE() = native javax.swing.WindowConstants.EXIT_ON_CLOSE;
<bonniot>very stange
javap javax.swing.WindowConstants [01:19 26/01/04]
Compiled from "WindowConstants.java"
interface javax.swing.WindowConstants{
public static final int DO_NOTHING_ON_CLOSE;
public static final int HIDE_ON_CLOSE;
public static final int DISPOSE_ON_CLOSE;
public static final int EXIT_ON_CLOSE;
javap javax.swing.JFrame [01:19 26/01/04]
Compiled from "JFrame.java"
public class javax.swing.JFrame extends java.awt.Frame implements javax.swing.WindowConstants,javax.accessibility.Accessible,javax.swing.RootPaneContainer{
public static final int EXIT_ON_CLOSE;13:16
protected javax.swing.JRootPane rootPane;
JFrame repeats EXIT_ON_CLOSE (and not the others)
<arjanb>this is an oddity in java api thus
i see: in JDK 1.3, EXIT_ON_CLOSE was not in WindowConstants, only in JFrame13:18
the others were in WindowConstants
there are probably trying to fix it without breaking existing classes
i think this is waht we can do:13:19
if a solution was found in a class, no need to look in its parent and implemented interfaces13:20
it will be faster too
<arjanb>that works13:45
<arjanb>SomeClass x = ...13:49
let y = x.staticfield;
this doesn't compile is that intentional?13:50
of course it's debatable13:52
but I don't see this as very logical nor important
<arjanb>i think it shouldn't compile13:53
the case x is null is quite strange
java throws NPE there but only since 1.413:54
just shows it's not a very clear feature13:57
<arjanb>java has still details where they not agree on even java exists for almost 10 years13:58
over 1000 testcases now14:07
* CIA-3 joins16:10
<arjanb>who has put this bot here?16:39
<arjanb>i see :-)16:46
* Quick-Nic joins16:50
* Quick-Nic hugs the bots
<arjanb>i see no reason for the syntax of string literals and multiline string being different17:01
<bonniot>one problem with this is that if you forget to close a " then it will run until the next opening ", and the parse error might be weird17:05
<bonniot>it's the same with """ of course, but those are less frequent17:13
<CIA-3>03xoltar * 10Nice/stdlib/nice/functional/ (generator.nice iterator.nice): 19:24
New iterator/generator library. Provides a number of methods for dealing with
iterators (i.e., Java-style Iterator<T>), and generators (Nice methods void->T
which return a new element on each call, and throw GeneratorEnd when they don't
have any more elements to yield). Things like map, filter, fold, zip, unzip, and
so on.
* CIA-3 leaves19:45
* CIA-3 joins
<Bluelive>alpha uses <" to ">fot multiline strings, that way you can just use " in them20:38
<bonniot>in Nice it's """ and you can use " too
<Bluelive>alotuhg there is no way to escape "> into one of those strings
<bonniot>the good thing about <" is that you know it's opening
<Bluelive>inspired by the old basic interpreters ?
it has the visually nice effect of closing most metadata with a ">)] sequence ;)20:39
<bonniot>""" is python's syntax too20:42
* CIA-3 leaves22:51
* CIA-3 joins
<bonniot>arjan, what do you think about brian's post on enums?23:06
<arjanb>enums extending user defined classes is possible but then is compatibility with java 1.5 impossible23:09
<CIA-3>03xoltar * 10Nice/stdlib/nice/lang/using.nice: (log message trimmed)
Implementation of the 'using' statement, familiar from
C#. Essentially, this code:
let f = new FileOutputStream("hello.txt");
f.write("Hello, world!".getBytes());
<Bluelive>where does cia get the event for this message ?23:10
wiki ?
<bonniot>arjanb: what would be the incompatibility23:16
Bluelive: cvsroot commit script
<arjanb>using nice enums in java 1.5
<bonniot>do you know how enums are compiled in java 1.5?23:17
<arjanb>not exactly23:18
<bonniot>so it's not clear what would be possible or not, no?
Bluelive: welcome to nice-info!23:19
<arjanb>i know they use an abstract enum class as base class for every enum
<bonniot>so that class could extend other classes, no?23:20
<arjanb>the abstract enum base class is the same for every enum23:24
<bonniot>ah ok
but if you compile a Nice enum and it's valid bytecode, it should be usable from Java23:27
<Bluelive>imwondering whats the point of the using thing from xoltar23:28
<bonniot>arjanb: maybe that would not work with the switch statement, though23:30
Bluelive: the resource is disposed at the end, like with a try/finally, but with a lighter syntax23:31
<arjanb>daniel: and EnumSet and EnumMap won't work either then
and i'm not sure what javac will do with enums not extending the abstract enum class23:33
enum elements are stored in fields with a new bytecode modifier to make reflection possible23:34
<bonniot>they modify the bytecode?23:38
or these are just bytecode attributes?
<arjanb>just a modifier23:39
like volatile transient private, ...23:40
<arjanb>what are your plans with supporting java 1.5?23:51
<bonniot>basically like before: Nice is 100% source compatibly, but syntax should be similar when possible00:02
and bytecode interoperability is needed00:03
<arjanb>and an option the generate java 1.5 bytecode?00:05
<bonniot>what do you mean?00:06
<arjanb>-the +to
<arjanb>so that nice code could be used in java as if it was java 1.5 code00:08
<bonniot>what feature are you thinking of? generic classes?00:13
(I think bytecode is unchanged for 1.5, apart from this enum modifier)
there is an attribute that contains the generic types of methods
and a new attribute for metadata00:15
<bonniot>yes, we can always generate those attributes
they won't hurt, since they're not part of the bytecode itself
<arjanb>good night00:41
* arjanb leaves00:42

Generated by Sualtam