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

Using timezone: Central European Time
* arjanb leaves03:25
* bonniot joins10:24
* arjanb joins12:39
<DRMacIver>Nice tuples are covariant in the types of their entries, right?13:21
<bonniot>yes
<DRMacIver>Thanks, that's what I thought.13:22
* DRMacIver is vaguely wondering what sort of syntax one could provide to allow user definable covariant types in a way that doesn't suffer from the mutability problem.
<bonniot>read-only fields are already covariant13:23
<DRMacIver>How do you mean?
(i.e. I have no idea what it means for a field to be covariant. :) )
<bonniot>you can redefine it to be of a subtype in a subclass13:24
<DRMacIver>Oh, right.
<bonniot>using the override keyword
<DRMacIver>I guess what I mean is cases where Foo<T> can be regarded as a subclass of Foo<S> when S <= T. 13:25
<bonniot>class Foo<+T> then13:26
<DRMacIver>Hm? What does that do?
<bonniot>i guess you meant T <= S though
otherwise that would be Foo<-T>
<DRMacIver>Yes, sorry.
<bonniot>declare T as co/contravariant respectively
the compiler will check it is safe, of course13:27
<DRMacIver>Ah
<bonniot>like: class Ref<+T> { final T value; }
<DRMacIver>Very cool.
I suppose this isn't documented anywhere? :)13:28
<bonniot>seems you are right, as the only occurence of "covariant" in the manual is about tuples
:-/
must be in the NEWS file though13:29
normally NEWS has all the news
the manual is updated when somebody finds time for it
mostly it was xoltar who did it
<DRMacIver>Ah. I should be better about reading the NEWS file then. :)13:44
It doesn't appear to be in the NEWS file though.13:49
<bonniot>that's right. surprising...13:51
but usage is clear now, isn't it ? ;-)
<DRMacIver>I think so. :) 13:52
* dbonniot joins14:41
* bonniot leaves14:43
<DRMacIver>Ah, neat. Nice has || for coalesce.16:36
* MarkH_ joins19:47
* MarkH_ leaves19:49
* MarkH_ joins
<DRMacIver>Hi MarkH_ 20:03
<MarkH_>hi.20:04
i noticed that the reply over at Lambda to your Nice post was "but when was the last time there was a Nice release...."20:05
DRMacIver: screw your PhD. I think you need to petition Sun to hire you to work on Nice. Forget about JRuby:)20:06
<DRMacIver>Heh20:12
It is a problem though. Nice could really use some more frequent releases. 20:13
But there aren't enough people working on it for that really.20:14
And I'm still being useless at getting started for various reasons.
<MarkH_>I'm more useless than you
<DRMacIver>(Although I frequently think that what Nice needs is better documentation. There's a lot more there than is actually visible.)
<arjanb>a new year, time to set new goals for Nice?
<MarkH_>have you written any Nice code that uses Swing?20:15
<DRMacIver>I don't really do GUIs.
<MarkH_>new goal? domination of the JVM?
<DRMacIver>But have you seen NiceSwing?
Or whatever it's called
<MarkH_>yeah...a little. i just want a little example that uses raw Swing though
<DRMacIver>Well there's probably a lot of code in NiceSwing that uses raw Swing. :)20:16
<MarkH_>I got sick of wading through CVS and figured that much of it was probably broken anyway. i never could get it built20:17
<dbonniot>there should be a built version available. isn't it linked from the wiki page?
<DRMacIver>Not sure. I've never tried building it.20:24
err. Using it.
How much thought has gone into adding visibility modifiers to Nice so far?20:35
It seems like a really silly stumbling block to be preventing release 1.020:36
<dbonniot>well, it is one the most recent features, so it can still take some tweaking
yes, except as you know the interaction with multi-methods is not always trivial
<DRMacIver>Wait, recent features? I thought it flat out wasn't implemented except for some parser support which the compiler ignored?20:37
<dbonniot>no, it should be enforced20:38
already
<DRMacIver>It doesn't appear to be.20:40
<dbonniot>hum, what did you try?
<DRMacIver>I created a class with a private field foo (actually I reused one from an earlier test) and tried to set that field from a different file within the same package.20:41
Ah20:42
<dbonniot>is it also visible accross packages?20:43
<DRMacIver>It would appear that nice-current.jar isn't.
I'll check
<dbonniot>testsuite/compiler/visibility/expressions/private.testsuite20:44
hum, the first one is actually marked as a bug20:45
<DRMacIver>It appears to be visible across packages as well.
<dbonniot>so it seems visibility checking for fields is still missing
it should work for methods
<DRMacIver>But the problem might be that I'm using version 11 (that which was under nice-current.jar a few weeks ago) and the latest version appears to be 12...20:46
Ah, you're right. Visibility works for methods.20:48
* DRMacIver will just build a new one from source. :)20:49
Oh, odd.20:51
The versions on sourceforge don't match up with the versions nicec reports
I was using the latest after all
<dbonniot>what doesn't match up?20:52
latest release is .12, dev version is .1320:53
<DRMacIver>Hmm. The version nicec is reporting after a make install is .11
Maybe I'm using the old version still or some similar incompetence. :)20:54
<dbonniot>then you are building old sources, no?
<DRMacIver>Nope
Ah, right. Mystery resolved.20:55
Nice is installing to /usr/local/bin and my current nicec is sitting in /usr/bin
*headdesk*
<dbonniot>:-)
<DRMacIver>Is there currently a way to declare default constructors to be private/protected?21:02
<dbonniot>not sure about that21:03
protected surely not
<DRMacIver>Oh, Nice doesn't actually have the protected keyword at the moment, does it?21:04
<dbonniot>no. not clear what the meaning would be
but i think a private class should mean the def constructor is private21:05
but i don't think that's implemented
<DRMacIver>Hm. But there are clearly cases where one doesn't want the class to be private but does want to constructor to be.
<dbonniot>what does it mean for a nice class to be private?21:06
<DRMacIver>Same thing it means for anything else to be private I suppose. For internal use only. :) 21:08
The obvious case I can think of is that when you have one of several implementations you want to use internally but don't want to expose this difference to the outside world.21:09
(I know the implementations don't go on the classes themself, but it comes to broadly the same thing)
<dbonniot>the thing is, if there is no public constructor and no public method returning this type, then the outside world does not see the class21:10
<DRMacIver>That's not true.
Because methods can return supertypes of that class.21:11
And the outside world can then do dispatch based on that class.
<dbonniot>right. but they don't have to21:12
<DRMacIver>Well they don't have to access private variables either. :)21:13
Visibility by gentlemens' agreement is just a bad idea.
<dbonniot>no, it's not the same
<DRMacIver>I have a class Foo with two subclasses Foo1 and Foo2. I expose a method Foo giveMeAFoo(Bar bar) which depending on circumstances can return Foo1 or Foo2. But I don't wish to be tied to this implementation, so I don't want other people knowing that these might be different.
<dbonniot>yes, i see your point21:14
<DRMacIver>ok
<dbonniot>you get into interesting situations, like a private class extending a public abstract one21:17
<DRMacIver>Hm. I don't think that's a problem.
<dbonniot>but i think there already are some restrictions to handle that. ah, i'll need to refresh my memory
<DRMacIver>Because in order to instantiate the private class you need to provide implementations of the methods that made the abstract one abstract.21:18
<dbonniot>it is, because if you have a method foo(A), it does not need to be implemented since A is abstract
but then you cannot implement foo(B) if B is private
<DRMacIver>But it does, because the package that provided you with your A had to also provide an implementation of foo.21:19
<dbonniot>not if foo is defined in another package unrelated to the one defining B
<DRMacIver>Ah.
Hm
Actually I don't think I see why that's a problem specific to private classes. 21:20
<dbonniot>if B is not private, you can always implement foo when both B and foo are known
im the package that imports both21:21
<DRMacIver>Oh, well yes.
But that's a feature, not a bug. :)
<dbonniot>which one is a feature?
<DRMacIver>If the package does not provide me with more information about A than that it is an A and foo is a method that is supposed to be defined on A then either foo shouldn't be abstract or the package should have provided more specific information.21:22
That was poorly explained.
I'll try again. :)
<dbonniot>yes, i'm not sure i got you the first time ;-)21:23
<DRMacIver>The usage scenario I'm envisioning is that private classes are for hiding implementation details. So if I'm directly extending Foo with a private class where Foo is something which doesn't have very much information, then I've done something stupid.21:25
Because I'm providing a method without enough information to actually make use of it.
It would be like those bloody stupid methods in Java which return 'Object' :)21:26
So it should be the case that the public information provides sufficient information to use the return type.21:27
So anyone defining an abstract method on class Foo should also have enough information to provide an implementation.21:28
<dbonniot>yes, but what if they decide not to?
what should the compiler report?
because i don't think it's OK to accept it can happen that importing two packages creates an impossible situation that cannot be solved21:29
<DRMacIver>Well it can be resolved by providing a default implementation of the method for Foo. :) 21:30
<dbonniot>sorry, but i'm quite tired, so i badly need a break. we should continue this later or another day... ;-)
<DRMacIver>ok, no problem. Take care.
<dbonniot>but you cannot, if the method is defined in a package you import
of which you might not have the source
<DRMacIver>Why not? Can't you just override the method? 21:31
<dbonniot>oh. well usually override is for a more precise class, but now there is not, since Foo was already known21:32
but that might be feasible
still, the fact that there is a private non-abstract subclass is "leaking" information, no?21:33
so i think the right solution is that it mist be taken into account from the start that there might be private subclasses later
but i'm not fresh enough to continue
later...
:-)
<DRMacIver>ok. Bye :)21:34
(hmm. You're right actually. This is trickier than I thought)21:35
Hm. I swore you could override based on parameter names. Am I going mad?22:16
Ah22:17
You can do it for constructors but not for methods.
That's... odd.
<dbonniot>well, the difference is that in constructors names are required at the call site22:21
<DRMacIver>Ah, I hadn't realised that.22:23
Although come to think of it I should have as in retrospect an error I got earlier was because I tried to do without. :)
The overriding based on integer ranges is specific syntactic sugar for integers, right? There isn't a more general overriding on boolean conditions.22:53
* MarkH_ leaves23:27
* CIA-2 leaves
* dbonniot leaves
* ChanServ leaves
* DRMacIver leaves
* arjanb leaves23:33
* ChanServ joins23:34
* MarkH_ joins
* dbonniot joins
* CIA-2 joins
* DRMacIver joins
* arjanb joins23:37
<DRMacIver>Ah, the new version of nicec gives me more useful error messages in the nullness bug I reported the other day. :)23:40
(Same content, and the bug is still there, it's just actually readable now)
* arjanb leaves23:43
* MarkH_ leaves
* CIA-2 leaves
* dbonniot leaves
* ChanServ leaves
* DRMacIver leaves
* ChanServ joins
* arjanb joins
* MarkH_ joins
* dbonniot joins
* CIA-2 joins
* DRMacIver joins
* dbonniot leaves23:47
* arjanb leaves23:56
* MarkH_ leaves
* CIA-2 leaves
* ChanServ leaves
* DRMacIver leaves
* ChanServ joins23:57
* arjanb joins
* MarkH_ joins
* CIA-2 joins
* DRMacIver joins