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

Using timezone: Central European Time
* arjanb leaves01:38
* bonniot leaves03:03
* zdennis joins06:11
* zdennis leaves06:32
* bonniot joins09:56
* centaur22 joins10:15
* centaur22 leaves
* fcb joins12:11
<bonniot>hi frank12:12
<fcb>hello12:13
<CIA-3>03fbarber * 10Nice/src/nice/tools/doc/css.nice: Added stylesheet entry h3.listheading that isn't actually used yet. It will be used for the index page for packages.12:14
03fbarber * 10Nice/src/nice/tools/doc/htmlwriter.nice: There is now a new index page for the packages (as opposed to the index of packages). Definitions (eg, Methods, Classes, ...) are grouped according to the files they are in.12:16
<fcb>have a look - see what you thing of the new style
<bonniot>:-))
right ho
i was thinking, now there should be a way to give a global comment for the purpose of the whole file12:18
any idea?
<fcb>yeah, good point. that needs to be differentiated from the class comment in some way in the source file12:19
<bonniot>a bit like package.html is a description of the whole package with javadoc. but I guess for files it should be embedded inside the file
<fcb>yep12:20
<bonniot>"the class comment" ? there can be no or many classes in the same file in Nice ;-)
but yes, i see your point
and the first /** is not a good idea, because that can be a license header (like we do)
<fcb>yes. but I would be nice to keep in with the general /* comment style if we can12:22
<bonniot>agreed
btw, did you read the irc logs. cm_ has some ideas about nicedoc, and he seemed ready to contribute too12:23
<fcb>I haven't read that. Where can I find them?
<bonniot>http://confer09.condor-edv.com/nice@freenode/2004-09-16.html I think12:24
<fcb>thanks
<bonniot>let's see these new docs ;-)12:25
<fcb>it could be last /** after all the code, but that's not very logical really
<bonniot>wow, javascript!
<fcb>yeah12:26
<bonniot>it's cool ;-)12:27
<fcb>thanks!!
I was trying to be a bit creative
<bonniot>:-)
are the files in random order?
<fcb>at present, yes12:28
but that can be changed easily
<bonniot>i guess alphabetical would help if you look for something specific12:29
* arjanb joins
<bonniot>i think there will be online docs soon ;-)
<fcb>I hope so!12:30
I have to go now, but I'll have a think about the file comment thing and also make the files sorted alphabetically
It would be good if I could have a chat to cm_ at some stage as well
<bonniot>ok. we'll have to be diligen with writing comment now ;-)12:31
yes
dilligent
diligent, there
<fcb>you got there in the end :)
<bonniot>:-)
<fcb>anyway, talk you to soon12:32
<bonniot>btw, for methods that _have_ comments...
<fcb>yes
<bonniot>the /* and */ should be stripped
Method foreach
<T> nice.lang.void foreach(nice.lang.Collection<T> collection, (T)->void action)
<fcb>oooops :(
<bonniot> /** Perform action on each element of collection. */
no big problem, just cosmetics ;-)
<fcb>yep12:33
<bonniot>http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=modular+programming+language&btnG=Search12:34
third ;-)
<fcb>nice!12:35
ok, bye everyone
<bonniot>bye
* fcb leaves
* cm_ joins13:41
hi
<arjanb>hi13:42
<bonniot>hi
there's been improvements on nicedoc13:48
<cm_>ok, in cvs?
<bonniot>yes13:49
frank was here an hour ago
<cm_>is sf down?
cvs update
cvs [update aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused)
<bonniot>yes, there's a pb on SF13:50
<arjanb>anonymous cvs is down
<cm_>ok
<bonniot>"for projects that start with the letters m, n, p, q, t, y and z" !!
<cm_>heh13:51
<bonniot>i'll put up a copy of the sources, OK?
<cm_>great, with cvs info?13:52
<bonniot>it will have the CVS dirs for me, but why?13:53
<cm_>In order to be able to update later. Any info from sf when/if/how it is up and running again?13:54
<bonniot>see the SF status page13:55
no, it'll have my username is CVS/Root
i can't get an anonymous checkout either :-P
<cm_>ok, no hurry13:56
<bonniot>the tgz is on its way13:57
<cm_>Or change the name of nice to something else ;-)
<bonniot>:-)
<cm_>btw, Is sf going to support subversion?13:59
<bonniot>http://nice.sf.net/tmp/Nice.tgz14:01
<cm_>thanks!
<bonniot>i hope so, but they are pretty conservative (and overwhelmed) so it might take some more time...14:02
<cm_>Hope so to, cvs is rather obsolete
About the constructor syntax: Why are not assignments permitted in constructors?14:47
<bonniot>what kind of assignments?14:48
<cm_>To members
<bonniot>the thing is that 'this' is not accessible yet because it's not in a valid state14:49
instead of
this.x = foo;
you can do:
let x = foo;14:50
...
this(x: x, ...);
}
<cm_>Ok, reason for this design choice?
<bonniot>the first criterium is correctness14:51
Java, by letting you access this before it's built, allows incorrect code to pass
<cm_>Example?
<bonniot>(that bites you when you call a method in the constructor, and that method is overriden)
that must be on the wiki, let me look14:52
<cm_>http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/ConstructorSyntax
How do you override the default constructor?14:54
typo on wiki: custructor. :-)
<bonniot>wikis are made so anybody can fit them (hint ;-)14:55
<cm_>heh
<bonniot>i think there is a specific Java example...
yes: http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NiceConstructors14:56
First, let me explain why "regular constructors" are not perfect either. The most obvious problem is that they are inherently unsafe. They allow you to refer to this inside the constructor, even before the object is completely constructed.
Here is a simple example, in Java:
class Parent {
Parent() {
// We want to log the construction of Parent objects
Logger.log("Instance created: " + this);
}
public String toString() {
return "Parent";
}
}
Is this class correct? One would easily think so. And indeed, it will work properly by itself. Now imagine a subclass is created:
class Child extends Parent {
/** @file a non-null File */
Child(File file) {
this.file = file;14:57
}
private File file;
public String toString() {
return "Child, with file: " + file.getCanonicalPath());
}
}
Apparently, we did nothing dangerous. First thing done in the constructor is to set our private field. We require that the given file is non-null. So toString should never fail with a null pointer exception, right?
Well, it will. This is because the parent constructor is called before the child constructor. And the parent calls toString, when the file field is not set yet. Boum!
<cm_>'14:59
I agree
But doesn't this state problem apply for "init functions" as well?15:02
<bonniot>not if you use the instance initializer15:03
<cm_>Yes, but that implies that certain rules are followed 15:04
<bonniot>that's why the compiler is enforcing the rules about fields. or do you have something else in mind?15:05
<cm_>The state problem is inhertied from the inheritance paradigm
<bonniot>inherited, that's the right word ;-)15:06
<cm_>hehe
Not quite
<bonniot>but do you see any problem with Nice's current system?
<cm_>It solves one problem15:08
But not the general problem with inheritance 15:09
<bonniot>can you state it?
<cm_>That you can never, in general, know the value of specific fields (or state) without having the source code.15:11
From the superclass
<bonniot>that's a feature, not a problem ;-)15:12
sometimes the value is an implementation detail
if it matters, then you can use contracts to specify that
(or types, as a special type of contract that the compiler can enforce, like being non-null)15:13
<cm_>just a moment, on the phone
Ok, but it is not about specific fields or semantics that could be enforced by the compiler. You could state the problem as you can't know the state.15:18
<bonniot>yes, and i'm saying you shouldn't ;-)15:19
you should never rely on the implementation of the super-class (or any other class), because it can change, you should only rely on its contract
<cm_>And the contract is simple to define. Further, even more simple to prove correct ;-) I would say infeasible.15:22
It is about conventions and that applies to constructors as well.15:23
<bonniot>of course I'm presenting the idealized view. but defining contracts is important, even if can never be perfect
what the more, it's hard to prove the contract, but then it's even harder to prove the whole code is correct15:24
contract help you there by limiting the effects
<cm_>Yes, I agree. My point is that if you define a postconstructer, call it init(), you would have similar state problems as with the constructor.15:26
<bonniot>agreed15:27
the difference is that at the end of the constructor, and so before the begining of init(), the object is in a valid state15:28
and it should stay like that afterwards
so you might have some race conditions, but much less, and less catastrophic, than when messing with the constructor15:29
<cm_>Yes, conventions then
<bonniot>yes. as far as I know this is not the job of the language designer anymore ;-)
(but maybe we'll discover a great new way to do initialisation ;-)15:30
(once we take for granted the benefits of the current system, and come upon cases that need more)15:31
<cm_>My concern is regarding having a syntax not similar to Java. I think it is in general a bad idea apart from when the benfits are significant.
<bonniot>yes, i have the same philosophy15:32
here there is a benefit
<cm_>That is subjective
<bonniot>that said, we could allow a similar syntax, only do the additional checking
the current system is just the eaysiest way to do it15:33
but we could allow
assignments to this.field
then we have to check all field are definitely assigned
and still disallow calling method passing 'this'15:34
that would be a more familiar syntax
<cm_>Fair enough. I think that would be much better.15:35
<bonniot>have you read my blog entry about constructors?15:36
<cm_>nope
<bonniot>http://216.239.59.104/search?q=cache:MQ8q94Dlva0J:www.jroller.com/page/dbr/20040309+&hl=en&client=googlet15:37
<cm_>Some people really thinks inheritance is optimal. In fact, inheritance is burdened with a plethora of problems but that is another discussion :-)15:38
<bonniot>it's generally a bad idea to think something is optimal. it prevents you from finding better. one should be open-minded about those things15:39
that said, there are different ways to design a language with inheritance, and some have less problems than others ;-)15:40
<cm_>Very true. I was amazed when a declared different problems with inheritance to some people with a masters degree in cs. They didn't have a clue... :-)15:41
<bonniot>can't read your sentence
?15:44
<cm_>Ok, that some people don't are aware of the problems related to inheritance. 15:46
<bonniot>ok, thanks
<cm_>I read a report from IBM a while ago. They had severe abi problems with a program that relied on java.* inhereted classes.15:47
So what is the moral? Never inherit classess out of your control.15:48
<bonniot>like, never inherit Object? ;-)15:49
<cm_>heh
bonniot vs cm_, 1-0.
<bonniot>:-)15:50
* bonniot is away: lunch...
* bonniot is back (gone 00:24:22)16:14
<cm_>Bye. Let us all pray for the return of anonymous cvs at sourceforge :-)18:36
* cm_ leaves
* zdennis joins23:27
<arjanb>hi
* zdennis leaves

Generated by Sualtam