[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Lava, coordsyscache
From: |
Matti Katila |
Subject: |
Re: [Gzz] Lava, coordsyscache |
Date: |
Tue, 29 Jul 2003 19:15:10 +0300 (EEST) |
On Tue, 29 Jul 2003, Tuomas Lukka wrote:
> On Tue, Jul 29, 2003 at 10:31:20AM +0300, Matti Katila wrote:
> >
> > Uh, I feel like a dumm. Ok, takes some hours to fix this.
Now enough hours later I can say, phhh...
> ;) Nevermind, it happens - libvob is a complex system with lots
> of features.
>
> At the same time, could you think what we need to do to fix the docs
> so that this wouldn't have happened?
First someone should document how this makes sense?
public void chgFast(VobScene oldVS, int parent) {
p("parent: "+parent+" to make chgFast: "+oldVS.matcher.getKey(parent)
+ ", foo: "+ oldVS.matcher.getCS(oldVS.matcher.getKey(parent)));
...
AreaSelectingView2D:: parent: 199 to make chgFast: address@hidden, foo: -1
So, 199 == -1?
Should I have guess that this works only if parent is cs number 0?
public int getCS(Object key) {
if(key == null) key = NULL;
return getCSByKeyObject(new Key(key, 0));
}
public int getCS(int parent, Object key) {
if(key == null) key = NULL;
return getCSByKeyObject(new Key(key, parent));
}
I understand, after some thinking, why it's so, because of recursive
coordsystems, but it for example can be written in javadoc - thank you.
So, coorsys number <=> matching key is not true.
-Matti