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

Using timezone: Central European Time
* khc joins00:52
<arjanb>how is it going with Nice?00:55
<khc>I tend to try to write an editor whenever I learn a new language/toolkit.01:05
Oh right, I had a problem last night:01:06
When I add a component by calling JTabbedPane.add(c), I am using a subclass of JComponent (JPanel), when I want to get the selected compoenet, I call JTabbedPane.getSelectedComponent(), but there's no way to cast it back to JPanel?01:07
JTabbedPane.getSelectedComponent() returns a Component btw.01:09
<arjanb>an editor to learn a new language, interesting idea
<khc>Well, when I am done, feel free to use it as an example or something.01:11
<arjanb>so a JTabbedPane can have multiple components of different types?01:13
But in my case, I know that I will always put a JPanel in there.
Well, a subclass of JPanel
<arjanb>you could use an instanceof to upcast it or make method doing that conversion01:14
<khc>How do I use instanceof to do the job>?01:15
And what do you mean by "make method doing that conversion"?01:16
<arjanb>Jpane asJpane(Jcompoment x) = throw new Exception();01:19
asJpane(Jpane x) = x;
without typos:01:21
JPanel asJPanel(JComponent x) = throw new Exception();
asJPanel(JPanel x) = x;
and the other way is:01:23
let sc = x.getSelectedComponent()
if (sc instanceof JPanel) {
.// do things with the Jpanel
<khc>Oh, so if I put code inside a block like that, I can call methods found in JPanel?01:24
<arjanb>instanceof does an implicit cast in Nice
<khc>But the first way seems to be exactly the same as casting, so why isn't Java-like casting allowed?01:25
<arjanb>a Java-like cast is rarely needed in Nice and you can avoid them with instanceof's01:28
<khc>Except that I know instanceof is going to return true already.
I tend to think that a language should only protect people so much.01:30
<arjanb>in case of Collection or List the compiler can know what in it because of the type parameters01:31
only that isn't possible for things that can contain different types01:32
<khc>Right, I am saying that in my case, a simple casting is a more obvious thing to do.
<arjanb>true we are thinking about taking assert statements in account by type inference01:33
so can you could say assert sc instanceof JPanel;01:34
<khc>Er, that means instead of if(sc instanceof JPanel), I do assert(sc instanceof JPanel)
<arjanb>not a big difference but it keeps the indentation flat01:36
<khc>So casting will never be allowed?
<arjanb>there is a cast function in Nice01:37
<arjanb>JPanel jp = cast(x.getSelectedComponent())
<khc>Ah cool.01:38
<arjanb>although Nice tries to do much more compile time cheching, it should not get in the way01:53
<khc>I concur.
<arjanb>but for interfacing with java there are certainly a few things that should be improved01:54
<khc>I think Nice should get some more publicity.
<arjanb>we will promote it more actively when it gets to version 1.001:57
i think publicity isn't the biggest need atm01:59
<khc>Oh, I agree. The compile time really need to be cut down.02:00
<arjanb>yes but niceswing is the worst one i know in that respect02:03
<khc>Oh, you mean some components are not wrapped yet?02:08
<arjanb>i mean the worst in compile time02:09
Also, I notice a file called package.nicei, is that file necessary, or just some caching to make compile faster?02:12
<khc>So what will happen if I remove it?
<arjanb>it's needed when the Nice source isn't available
<khc>Oh, the what does Nice do when I import a java package?02:15
<arjanb>and otherwise it just avoids that the package needs to be recompiled every use
<arjanb>for Java packages it's not needed/used02:16
<khc>What's making the difference necessary?02:17
<arjanb>nicec needs more info than normally is in classfiles to use compiled Nice packages02:19
<khc>Why's that?02:20
<arjanb>more precise types in Nice, multimethods02:21
<arjanb>in the long term package.nicei should go away
<khc>Also, the reason why nicec reproduce nice.lang, nice.ui.* whenever I recompile is so that the resulting jar file can be run w/o nice dependencies, correct?02:23
<arjanb>for nice.lang yes but i'm not sure about nice.ui.*02:25
<khc>nice.ui.common is also in there.
<arjanb>right though it's not because of running w/o dependencies02:47
<arjanb>for some features it's needed to modify class files of previous compiled Nice packages02:50
<khc>Hmm, that doesn't seem to be a long term solution?02:52
<arjanb>the bytecode specification is too restrictive to do it otherwise02:53
<khc>Which features would those be?02:56
<arjanb>mainly for multimethods02:57
* CIA-6 leaves04:12
* CIA-6 joins04:13
<khc>Doesn't that mean there's a problem with any libraries written in Nice though?04:29
<arjanb>not that i know05:02
<khc>well, you were saying that classes need to be rewritten to support multimethod? So how to ship a compiled library?05:04
<arjanb>that can be a jar file as usually05:10
<khc>Right, so if I write an app that uses a library, is it going to rewrite the files?05:12
<arjanb>if the app and the library is written in Nice yes05:14
<khc>So we need to ship all the libraries that we use?05:18
<arjanb>i think nice apps will be all in one jars05:20
* arjanb leaves08:18
* arjanb joins11:57
* CIA-6 leaves12:20
* CIA-4 joins
* CIA-4 leaves14:08
* CIA-4 joins
* CIA-4 leaves14:53
* CIA-4 joins
* fcb joins16:05
* fcb leaves16:06
* fcb joins16:11
is anyone available to answer a question about Nice programming style?16:12
* CIA-4 leaves16:15
* CIA-4 joins16:16
<khc>fcb: Maybe.17:08
<arjanb>hello frank18:16
<khc>Who's Frank?18:17
<arjanb>fcb = Frank
* CIA-4 leaves19:30
* CIA-4 joins
* CIA-4 leaves21:26
* CIA-4 joins21:27
* CIA-4 leaves
* CIA-4 joins
* arjanb leaves23:03