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

Using timezone: Central European Time
<arjanb>storing docStrings is possible now02:10
<bonniot>good!02:56
good night
<arjanb>good night
* bonniot leaves03:01
<Bluelive>hmz03:22
parametrics cost quite allot per instance if you decide to take the type along for the ride (so that new would work, and reflection could stay safe)
funny how optimizing can sometimes fix bugs03:36
<arjanb>or can create bugs you find months later03:38
* arjanb leaves04:32
* Bluelive leaves05:31
* Bluelive joins
* Bluelive leaves05:46
* Bluelive joins05:47
* Bluelive leaves
* Bluelive joins05:48
* arjanb joins11:27
* BlueLap joins13:46
* BlueLap leaves16:37
* bonniot joins20:15
hi20:18
<arjanb>hi
<bonniot>why give priority to vars above methods?20:21
<arjanb>because i find it annoying to rename globals only because somewhere exist a method with the same name20:22
<bonniot>in a different package?20:25
<arjanb>could be20:27
<bonniot>i think in the long term there will be priority of the current package over the other ones (like for classes)20:28
but for now this is an OK workaround20:29
i'm not sure it should be a permament feature though
<arjanb>we can see if it's still needed when all scoping/visibility things are improved20:32
have you decided between this(...) or new(...) in CCs?20:33
<bonniot>didn't think again20:39
was is the current implementation?
<arjanb>this(...)
(funfield)(arg) == funfield(arg) //error 20:42
(this.funfield)(arg) == this.funfield()(arg)
i tried to make (funfield)(arg) possible but it's no easy doable20:44
<bonniot>i'm working on it
using givePriorityToFields
<arjanb>i'm beginning to prefer stricter rules for parentheses at calls /field accesses20:48
<bonniot>like what?20:49
<arjanb>() is always a call and fieldaccess are without ()20:51
<bonniot>and how do you allow the change of a field to an accessor without modifying clients?20:53
<arjanb>x.field <-> x.getField() and x.field = y <-> x.setField(y)20:55
and make these interchangable on both implementation and calling site20:58
<bonniot>what would the stricter rules bring?20:59
<arjanb>less confusing code21:00
<bonniot>can you give an exmaple?21:02
<arjanb>this.funfield(arg) this will yield an error while i expect it to call that function object21:03
<bonniot>and what would your rule do?21:06
<arjanb>fields don't have () so you calling what thing that the field contains21:08
<bonniot>it would be possible to see that funfield is a field, so it needs only one argument21:09
so interpret it as (this.funfield)(arg)
no need to change the syntax I think
<arjanb>but what in case of an no arg function object21:10
<bonniot>right21:11
<arjanb>it's confusing (this.field)() meaning different than this.field()21:13
<bonniot>with my patch you can simply write field()
<arjanb>then are field() and this.field() different?21:15
<bonniot>yes21:16
<arjanb>confusing21:18
<bonniot>i think we could reconsider this when properties are implemented. then it will be more clear what is needed for fields21:20
<arjanb>agreed
<bonniot>the patch for implicit this seems to work well21:26
<arjanb>then i have only tried the wrong place to fix that21:27
<bonniot>what did you try?21:28
<arjanb>to add this in analyseIdent
<bonniot>I do it in OverloadedSymbolExp, in case of error21:30
so if you have
foo(y)
it first tries to see if foo is a field of y
if not, it tries (this.foo)(y)
<arjanb>i see21:31
i get lost the the last nice-info thread21:42
<bonniot>which one?21:43
<arjanb>Re: [Nice-info] Re: Eiffel Agent ~ Ready to Evaluate Functional?
maybe i'm missing some mails but i can't check because the web archive is a few days behind21:44
<bonniot>you could use gmane
do you have a news reader?21:45
<arjanb>yes but gmane has a webarchive too21:46
<bonniot>you can use either21:48
so no problem!
<arjanb>what do you think of the 2 newest open bug reports?21:59
i would say not a bug but i'm not sure22:32
more feedback about CC on wiki22:37
<bonniot>about for: I agree with Isaac this is surprising23:13
logically it should be:
for(val i : 1..10) ...23:14
like expression variables
<arjanb>i'm not sure it's surprising enough to change23:19
<bonniot>i'm not sure23:37
but it's inconsistent
* lodewijk joins23:41
hello23:42
<arjanb>hi
<lodewijk>anyone know why I can't say this:
interface A {}
interface B<S, T> extends A {}
without having the compiler complain?23:43
<arjanb>different number of type parameters in superclass is not possible yet
<lodewijk>arjanb: but it will be someday?23:44
and is it possible to hack around this? I want to write a generic implementation of Swing's TableModel..23:45
<arjanb>this limitation will be removed someday but daniel could tell more about that23:47
are the classes without typeparameter only java classes?
<lodewijk>arjanb: java interfaces is the first I bumped into this, yes.23:48
I tried:
interface KeyValueTableModel<K, V> = native javax.swing.table.TableModel;
but that somehow makes the compiler complain about totally separate files that extend the regular AbstractTableModel.23:49
<bonniot>interface KeyValueTableModel<K, V> = native javax.swing.table.TableModel23:51
<arjanb>you gave TableModel typeparams so AbstractTableModel that implement TableModel does need the same number of type params
<bonniot>is basically giving a new name to TabelModel, and saying that it has two type parameters
so its subclasses also need the type parameters23:52
does it make sense to say TableModel has type parameters?
<lodewijk>aha.. 23:53
bonniot: no, it doesn't, but it does make sense for my implementing class to have them, but the compiler won't let me.
so this was an attempt to sidestep the issue. didn't work :)
<bonniot>because the values in different cells could have different types, right?23:54
what does your generic implementation look like?23:55
<lodewijk>bonniot: yes. I'd like to make a class implementing the table model that takes a Map, basically. and then just shows the keys and values in the map. that's the issue.
but not a java-style implementation with Objects all over the place, but nice'ly :)23:56
<bonniot>sure :-)23:57
<lodewijk>the implementation I tried extracts a SortedSet<Map.Entry<K, V>> from the map. then the most interesting bit is getValueAt() which is return col == 0 ? entries[row].getKey() : entries[row].getValue();
bonniot: you are the initiator of the whole Nice project, correct?23:58
<bonniot>yes
<lodewijk>bonniot: okay, well, very many thanks to you then. I don't like Java, I like Haskell, but now I'm forced to come up with some java bytecode that does some pretty things, and Nice makes it a whole lot nicer :)23:59
<bonniot>great!
have you been around on nice-info?00:00
<lodewijk>bonnoit: I'm waiting for my confirmation mail to subscribe to come in :)
<bonniot>ok00:01
<arjanb>the mailinglists are delayed again
<bonniot>this variance between subclasses has been a pain for sometime. comes up from time to time...
<lodewijk>bonniot: it kindof surprised me. I've worked with Eiffel, saw that it's all somewhat similar here, so just assumed this would work.00:03
<bonniot>it seems you need the extension to have a completely clean solution
would it work for now to do:
class MapTableModel implements TableModel
{
Map<Object,Object> map;
}
then you can do your implementation
when creating your MapTableModel, you will need to cast your map00:04
but as long as you don't add new elements, which it seems you don't want, it will be safe
<lodewijk>bonniot: aha. okay, I'll try that.
bonniot: I've got to go now, but thanks again for a great language :)00:05
<bonniot>:-)
* lodewijk leaves
<bonniot>i'Ll go too. good night!00:07
<arjanb>good night
* bonniot leaves00:08

Generated by Sualtam