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

Using timezone: Central European Time
* arjanb leaves03:32
* lucp leaves04:05
* cm_ leaves08:44
* cm_ joins09:52
* arjanb joins12:18
* pitecus leaves14:08
* cm_ leaves16:21
* bonniot joins16:36
* cm_ joins16:59
* lucp joins17:02
<arjanb>hello luc17:03
<arjanb>you closed the bugreport about extending java classes but is the second problem solved too?17:46
<lucp>isn't it? maybe i closed it in error.17:50
<arjanb>i don't remember any change about subclassing java classes without public constructors..17:56
<lucp>sorry.. my mistake. i thought the comments said Daniel fixed it.17:58
<arjanb>no problem18:18
<lucp>i have a new solution for the protected member problem that should work in all cases19:31
<arjanb>even if the first argument is a java superclass?19:55
<lucp>yes, hopefully.. testing it right now19:57
<cm_>arjanb: What is the name of the .NET language with macros? (or kind of macros)20:28
<lucp>is there a test case in the testsuite for the protected methods?21:38
* cm_ leaves22:07
<arjanb>not that i know22:16
<bonniot>lucp: there are testcases for integration with Java in regtest/java22:22
<lucp>my fix is working correctly (no side effects as far as i can see), however i need to wait for my patch from yesterday to be committed.22:35
<bonniot>sorry, i won't be able to look at it today22:55
what does your new patch do?
<lucp>it makes it possible to call protected java methods by creating redirect methods22:56
<bonniot>cool. did you test it when the call is not in the same package as the one defining the Nice class?23:00
<lucp>no.. it should not be a problem provided that the nice class is being recompiled also..23:04
that probably should not be allowed anyway... it is a protected method after all :)23:16
<bonniot>i think the idea of protection is that you only need access when extending the class23:43
now with multi-methods, extending the class is not limited to the package you define the subclass
<lucp>right.. however, the only way to solve this problem is to add a method in the class file that extends that java class.. do you know another way around this problem?23:47
<bonniot>no, that's the way it should be done23:52
<lucp>in that case, this is a limitation we are stuck with if the nice class cannot be recompiled.23:53
<arjanb>i think protected java methods shouldn't be used outside packages where the extending nice class is defined, because that would make protected java methods public..
<bonniot>lucp: yes, but the nice class is normally recompiled anyway, for other reasons23:57
arjanb: it just shows that protected is meaningless in a language with multi-methods23:59
<lucp>right, we are just stuck to dealing with it in a jvm :(
<arjanb>yes it's meaningless for Nice but i don't think we should ignore it when dealing with java code00:01
<bonniot>lucp: but working around is doable, as you showed :-)00:03
arjanb: why restrict modularity?
* pitecus joins00:06
* CIA-10 leaves00:12
* CIA-7 joins00:13
<arjanb>i don't see any need to break the intention of protected00:14
anyway this issue isn't very important, just choose the simplest implementation of the workaround..00:16
* lucp leaves
* pitecus leaves01:15
* pitecus joins01:47

Generated by Sualtam