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

Using timezone: Central European Time
* arjanb leaves08:04
* bonniot joins10:04
<DRMacIver>Semi-philosophical question. Why is a constructor not just a type of method?12:44
Other than backwards compatability reasons. :)12:45
<bonniot>there is a deeper reason
<DRMacIver>Good good. What is it? :) 12:46
(I'm just running over the sketch of the possible article I mentioned while I battle with JDBC, and this got me on to wondering about the above)12:47
<bonniot>well, one aspect is that i has to make sure that at the end an object is created in a valid state
in particular, that all fields are assigned
<DRMacIver>ok. But isn't that irrelevant if you don't have any way of accessing objects in an invalid state?
<bonniot>another reason is that a constructor of a class must call a constructur of the superclass12:48
<DRMacIver>i.e. there's no difference between 'making sure an object is created in a valid state' and 'returning an object'.
Ah. That's a good point.
<bonniot>right, that's the difference
otherwise, i guess what you meant is that instead of constructors we could have methods returning a new instance12:49
but yes, in class A a constructor cannot do new A(), because maybe you want a B
<DRMacIver>ok, yeah. I completely neglected the role of inheritance in this. That blows my point out of the water. :)12:51
As I should have realised, given that the only languages I know of which do things like this don't handle inheritance very well (if at all)
<bonniot>no problem
another way to discover all the fine points is to try implementing something ;-)12:52
<DRMacIver>Hm. How does the default constructor work with subclassing? Does it basically subsume (and call to) the default constructor of its superclass?12:53
<DRMacIver>Yeah, but it's harder to multitask implementing something with doing what I'm paid to. ;)
Hm. The default constructors are one of those features of nice which make me worried about how visibility rules are going to work.
e.g. suppose my object has fields foo and bar. But foo and bar are really calculated fields from an argument baz. So I want to make private the default constructor and make publically available the constructor which takes baz as an argument.12:56
<bonniot>getting paid: sure I understand that. i just mean it helped me learn a lot
<DRMacIver>But the subclasses' default constructors will still call to the hidden constructor.
I think what's needed here is a way to redeclare a new constructor as default.12:57
(I'll add that to my list of things to maybe look into if you want. :) )
<bonniot>i think it should be that if a constructor is not visible, it cannot be called, even by the default constructor12:58
so we might have situations where no default constructor exists (this happens in Java as well)12:59
i agree this has to be worked out more precisely. that's why we don't have 1.0 yet ;-)
<DRMacIver>But that seems a shame, because it blocks all your subclasses from having a default constructor.
Actually, how will that even work?
Because without a default constructor there's no way to set up the new fields is there?13:00
<bonniot>actually there are several default constructors
i mean that for every constructor (default or not) of the superclass, there is a "default" constructor with those parameter of the parent constructor plus fields of the current class13:01
<DRMacIver>Hm. I thought there was only one default constructor but some of its arguments had default values. Maybe I've misunderstood again. :)
<bonniot>no, you're right about that, default values are handled as optional arguments of the same constructor
that should work in your situation, shouldn't it?13:02
I didn't realise it was providing a constructor for each constructor of the superclass.13:03
That makes a lot more sense now. :)
<bonniot>feel free to do some tests, first i might have forgotten something, esp regarding visibility, second the implmentation might still have some bugs...13:06
<DRMacIver>Yeah, I plan to.13:07
* arjanb joins16:04
* arjanb_ joins17:07
* arjanb leaves17:20
<DRMacIver>Hm. I know Nice lets you define operators with something like `&&&` (int foo, int bar) { // implementatation }. Is there any support for postfixing operators?21:04
e.g. I want an operator * which is postfixed.
<bonniot>you can give a method any name using the ` ` form, but...21:05
the syntax is actually wired in the parser at the moment21:06
<bonniot>so what you can do without changing the parser is overloading any operator (including postfixed ones)
<DRMacIver>Ah, right.
<bonniot>it could be interesting to have a more flexible parser. i think you mentioned one, right?21:08
That's the starting point for my plan.
(As mentioned I'm unfortunately not likely to be able to start doing anything on it until the new year)21:09
* arjanb leaves21:11
<DRMacIver>(The reason I was asking about operator overloading is I was thinking of creating some type safe wrappers for the java regexp packages that didn't require one to use the abomination of code embedded as literal strings)21:12
<bonniot>that would be cool21:13
<DRMacIver>It's pretty easy to do if one can get the syntax to work. I don't imagine I'll do anything more complicated than creating things which evaluate to regexp strings.
<bonniot>you should be able to experiment with adding a couple of operators in the parser
<DRMacIver>(As that way I can bootstrap off the existing libraries)21:14
* arjanb joins22:00
<bonniot>arjanb, you also looked into an alternative parser, didn't you?23:19
<arjanb>yeah but that was quite a while ago23:25
i looked at antlr 3 because of the relative ease of adding a Nice backend23:39
<bonniot>is that available now?
<arjanb>yes though it still seems in beta23:40
<bonniot>yeah. it surely is mature enough though23:44
would that also make it easier to do user define operators?23:45
ok, i have to go. see you around...23:49
* bonniot leaves23:50