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

* arjanb joins12:02
* arjanb leaves19:56
* arjanb joins19:57
* bonniot joins20:56
<arjanb>hello20:58
<bonniot>hi arjan
i'm going to look at adding simple instance initializers, since Alex needs something like that20:59
<arjanb>do you know the syntax already?21:01
<bonniot>for now, I think like in Java, with braces21:02
<arjanb>without prefixed with some keyword?
<bonniot>no21:03
<arjanb>how about requiring it to be the first inside the class? or does that restrict the style of programming to much?21:07
i have tried to write some functional code today and one i thing i really missed is typedefs for function types
<bonniot>i think it might be restrictive21:08
one use of initializers is to have several, one for each different feature
for instance, one initlizer might do somthing with the value of a field, and so you would want to put it close to that field declaration21:09
<arjanb>i haven't thougt about multiple initializer yet21:11
* arjanb leaves22:42
* bonniot leaves
* bonniot joins22:43
* arjanb joins
<bonniot>yes, it should be possible22:54
<arjanb>one problem is that the the conditional types from previous null checks are difficult to get in lang.inline22:58
i will solve the newest bug report.23:05
<bonniot>do you know what's wrong?23:19
<arjanb>`+` is only overloaded for lists so concating two arrays yield a list23:20
<bonniot>ah, so it's not a difficult bug :-)23:21
there is already a concat method for arrays
<arjanb>fix is only one line
<bonniot>maybe it should just be renamed to `+`
<arjanb>not sure whether everyone prefer operator overloading over normal method names, i will keep both for now23:23
<bonniot>yeah, that's fine
i already have initializers that add code to the constructors
now i need to allow them to access the fields of the class...23:24
that's working now00:11
<arjanb>:-)00:14
how complex are you making the initializer? i can think of some features as: if you assign a field in a initializer then is that field not a required argument of the constructor00:56
<bonniot>no, initializers are not for giving values to fields01:01
that would be unsafe
see the discussion on the wiki, where I advocate separating construction and initialization
<arjanb>is the initializer automaticly called after construction?01:06
i will look at the testcases01:09
<bonniot>normally, it should be called in a second phase, after construction is finished
currently it is done just after construction, class by class01:10
this is why I put a bug testcase
<arjanb>so the initializers will later be in a seperate special method?01:11
i mean something like changing new A() internally to new A()._init()01:22
A _init() { super(); ..... return this;}01:23
this way it easier to get the initializer executed in the right order01:28
<bonniot>yes, something like that01:31
the inconvenient of that is that when the class is instantiated from Java code, the user would need to call the initializers manually01:32
<arjanb>isn't it possible to make the call to the init function at the end of a constructor?01:33
<bonniot>well, the problem would be then that when a parent constructor is called, it should _not_ call the init function01:38
that could be taken care by an additional boolean field01:39
but that could be bad to waste a boolean field in every object...01:40
<arjanb>a field? not an extra argument to the constructor?01:41
hmm an extra argument to the constructor wouldn't make it easier from java01:46
and doubling the constructor for direct and indirect calls isn't a good idea either01:48
<bonniot>yes, exactly01:52
we'll let this idea mature
for now, the initializer will already be quite useful, in particular for alex01:53
<arjanb>yes
i can understand why other language doesn't try to improve construction/initilization01:54
<bonniot>:-/01:55
without the compatibility with Java, there would not be a big issue01:56
<arjanb>the implementation is only part of the problem01:59
<bonniot>yes02:05
i'll be going...
good night
<arjanb>good night
* bonniot leaves

Generated by Sualtam