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

Using timezone: Central European Time
<bonniot>bye03:19
<arjanb>good night
* bonniot leaves03:23
* arjanb leaves03:24
* bonniot joins10:09
* bonniot leaves10:36
* bonniot joins
* arjanb joins11:55
<bonniot>hello arjan12:13
<arjanb>hello12:14
<bonniot>what's new?
<arjanb>nothing12:16
<bonniot>i found there is something missing from 'import a.* (!);'12:18
it should be exported like that in package.nicei
without this the feature is not really usable12:21
could you look at this?
<arjanb>yes
<bonniot>thx12:22
after that, i thought you could write to nice-info about the nice.lang retypings. hopefully somebody else could do that part...
<CIA-2>03bonniot * 10Nice/ (30 files in 6 dirs): 12:23
Separated high-level type operations (in nice.tools.typing.Types) from
the ones related to code generation (in nice.tools.code.Types).
<bonniot>i'll be away for a few hours...12:41
* bonniot is away: ...12:43
* bonniot is back (gone 02:04:27)14:48
<CIA-2>03arjanb * 10Nice/src/ (bossa/modules/Package.java nice/tools/code/Import.java): Put the strictimport in package.nicei15:23
03arjanb * 10Nice/stdlib/nice/lang/java-io.nice: Removed superfluous retypings from java-io.nice because of strict import.15:53
<arjanb>that's 3 minutes off running the testsuite16:09
<bonniot>:-)16:10
are thre other retypings to remove, or was this all?16:12
<arjanb>this is about all16:13
<bonniot>nothing at all in java.nice?16:16
<arjanb>only 516:20
afaik
<bonniot>that would be a start16:26
it seems to me there are more than that
<arjanb>public class Vendor {}17:31
public interface ITest {}
class testbug.Vendor implements ITest;
implementing a non abstract interface should that be possible?17:32
<bonniot>that could be interesting17:33
ha, it's a bug report17:34
<arjanb>yes the bug happens too when all is in a single package17:35
<bonniot>yes, that's normal17:36
abstract interface implementations have ne meaning in the bytecode
<arjanb>right but this interface isn't abstract17:37
so simply a check missing?
<bonniot>as i said on the list there is an Ai behind each interface17:39
and this is AI implementation
<arjanb>that surprises me17:40
the same for classes?17:41
<bonniot>there is no AI for each class17:48
<arjanb>every time i think that i understand the outside of the typesystem something comes up17:57
<bonniot>:-)18:00
that's just some syntactic sugar on top of it :-)
<arjanb>but it would be possible to externally implement normal interface when that class is in the same compilation right?18:04
<bonniot>yes. even if it is no, as long as we can include a modified version in the jar18:06
event if it is _not_ in the same compilation18:21
<CIA-2>03xoltar * 10Nice/web/manual.xml: (log message trimmed)19:11
Manual updates for 0.9.6
-Custom constructors
-Initializers
-Enums
-Main method should be outside of a class
-Block call syntax
<bonniot>i started to look at method specializations19:23
<arjanb>that's the same as adhoc covariant return types?19:24
<bonniot>covariant types is a use of it19:30
but it's more general19:31
<arjanb>have you other things in mind then?
<bonniot>the general idea is what brian formalized19:32
when a method has a smaller domain than another, then it's implementation also belong to the other one
... its implementations ...
that allows to handle Java type overriding (possibly with a warning)19:33
i guess with this, we won't need to compute removeNonMinimal each time in overloading resolution19:49
we can simply use the info about which method specializes which one
hum, that might not be right because of the info that is currently used about which arguments were default19:51
<arjanb>i think specilization should stay explicit19:56
<bonniot>that's still open to debate19:58
i think we might end up with a configurable warning19:59
<Bluelive>so20:45
and a few advanced features working :)
and also a new bug20:49
casting doesnt actually check if the parametric type is valid
<arjanb>half of the features added to nice has turned up a bug elsewhere in the code20:56
<Bluelive>:)21:06
what would you use as notnull expression ?21:07
prefix like !
or function ?
cast en convert use nice c++ syntax, though :)
conver<B>(whis())
<bonniot>there are funny issues arriving: what if package b imports package a, and both define a main(String[]) method?22:02
i guess we could say that there is no specialization when both methods have exactly the same domain22:05
and report an error if they are in the same package (which was requested recently, no?)
i found a public repository for the arch versioning system:22:17
http://sourcecontrol.net/
arch seems to have very interesting features
local local branches
my worry is that i'm not sure how easy it is to use on windows
any experience with it?22:18
<arjanb>i think each package should be able to have it's own main method22:57
there was a request for reporting error at identical methods22:58
i did see much benefits in arch over subversion and it looks less stable23:09
i don't
and their behaviour is annoying (spamming in comments of articles about the release of subversion 1.0 and ignoring the existing of other operating systems)23:13
<bonniot>main: agreed. i just wouldn't want to make a special case23:18
but i think the above rule is OK
arch: it allows local repositories, which is quite useful I think23:20
win32 is not ignored: http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support23:21
<arjanb>"Arch was never intented to run on a non POSIX system. Don't expect to have a full-blown arch on your Microsoft computer."23:31
<bonniot>i know, that's why i was worried. there are still people working on the port, so win32 is not ignored23:33
maybe we can completely get rid of the additional types in implementations:23:44
void foo(A);23:45
void foo(B);
foo(@B(A)) {}
foo(@B(B)) {}
now we would only need one implementation:
foo(B x) { ... }
<arjanb>and if you don't want that?
<bonniot>you do ;-)23:46
the point is, the methods having the same name and overlaping domains,
they should really represent the same "concept", otherwise your design is badly broken23:47
so they must behave the same way in the common cases
<arjanb>true but you can't always design all the packages you use23:48
<bonniot>but then they have different names, so you can specify the fully qualified method name23:50
<arjanb>A foo(A a) {}23:55
B foo(B b) {}
is this overloading or specializing?23:56
<bonniot>what is the difference?23:57
<arjanb>would the override keyword be required when using adhoc covariant returntypes23:59
?
A foo(A a) {}00:01
B foo(B b) {}
A foo(C c) {}
<bonniot>that's give an error at typechecking00:02
that'll give an error at typechecking
<arjanb>hmm00:04
package a;00:06
A foo(A a) {}
package b; import a;
B foo(B b) {}
package c; import a
A foo(C c) {}
package d; import b; import c;
error?
<bonniot>please include the class definitions, that could be important
<arjanb>in package a class A {} class B extends A {} class C extends B {}00:07
<bonniot>then you must implement foo(B) in package a, not in package b00:08
<arjanb>so you can't specialize a method from another package?00:10
<bonniot>you can00:11
the thing is that if both foo and B are known in a, then that's where you must implement foo(B)00:12
<arjanb>must?00:14
sorry but i'm a bit lost on the implications of unifying overriding and overloading00:18
<bonniot>well, as your example shows, one cannot be allowed to specialize a method in a package if that implementation could have been made in an imported package00:31
i think it's also bad practice to do that for implementations00:32
(even if you don't specialize the return type)
<arjanb>so this would be an exception to the general rule in nice that you can place everything everywhere00:40
<bonniot>there is no such rule (although it's true that we are much more flexible than most languages)00:42
for instance you cannot add a super class to an existing class (yet ;-)00:43
it's also consistent with the fact that even libraries must satisfy the link tests00:44
otherwise, you could accept uncovered methods in libraries, because the implementation could be written in an importing package00:45
this is the same idea
<arjanb>i see00:46
currently the coverage test is for every compilation, should that be for every package ?00:48
<bonniot>that could be quite expensive01:01
if you develop a library, you will likely compile that library independently, so you will get the errors if there are01:02
which should be good enough in practice
but you are right, that would be the strictest way01:03
<arjanb>i agree it would have little practical use
but it should be documented somewhere01:07

Generated by Sualtam