[Verse-dev] Numerical IDs [R4]

[Eskil Steenberg]

Hi
 
> Cool, I hope that went well!

No not realy, Siggraph failed to book the room, so no one at the 
site knew we where coming, and then they kicked us out. Im going to 
have words with Siggraph today...

> Well, I have to know that whatever ID I set my variable to cannot 
be
> sent by a host of course, otherwise there is no point.

Sure, we need a invalid value, the question is what should it be.


> Well.. That depends on how you organize your code, of course. If 
you
> wrap the concept of "an array that has a different base than zero" 
in
> a suitable data structure, the problem goes away.

Yes and no. in my exaple I can agree that i was extra mean. But take 
an example like Enough, i could wrap this beaoutefully. but still 
this would introduse problems for the user of enough. if read out a 
vertex or polygon form an array given by Enough and want to send a 
cange to verse you need to add 1 to the id of the elemnet you want 
to change. To wrap this i would have to wrap the entire verse send 
api too. not the smalest thing to do.


> That's a problem, of course. But wouldn't the same places in the 
code
> need to be looked over if there was some other reserved value?


> Yeah, well, I'd argue that the extra subtract is very cheap 
indeed.

sure, but it is also a add one, if you want to send changes. To
me, the biggest hassle is that you store localy a set of data that 
is addressed differently form the remote data. this conversion, is 
trivial but it WILL introduce bugs.

> The test is not "extra", you need to test against whatever value 
is
> reserved. Assuming it's the maximum and never happens isn't very
> nice, imo.

no, the test if the reference id is smaler then the length of the 
vertex array does this test automaticly, since the length of the 
vertex array can never be longer then (uint32)-2 .

> Yeah, well... It might be a point to keep the IDs zero-based just 
> so that they can be used to directly index arrays, I guess. It's
> just too bad that it then requires a bunch of other uglyness,
> casts and/or a set of macros to handle the reserved values.

I agree. you do have good points, but im afraid this may be the Im-
writing-a-verse-app-so-i-would-like-to-change-verse phenomenom...

E