Questions about Collections

Hi

I have somes questions about the collections.

I don't find how can I move into a Collections manualy (like after and before in B3d) is it possible ?

And of course I don't find how can I set my start position in a collection (last / first) is it possible too ?

Where can I find some documantion about TLink ?

Open brl.linkedlist, I think...

I have look at this module, and these functions are in the TLINK type.

I hope in the final version that the documentation will be more completed.


Method NextLink:TLink()
If _succ._value<>_succ Return _succ
End Method

Method PrevLink:TLink()
If _pred._value<>_pred Return _pred
End Method

Eole:
I agree with you. I've been banging my head against the wall trying to get my head round some of the new stuff. The language is looking great but the docs are decidedly lacking in proper examples and in some cases (such as list handling) the only way to make any sense of how things work is to study the module source. Another example - collisions are barely mentioned even though the new collision system is considerably more complex than Blitz 2d/3d. Without the example which was posted somewhere on the forums it would be impossible to make any sense of how it is supposed to work from the 'docs' supplied.

From Mark's Last Worklog Entry:


Hmm... don't get me wrong, I'm really impressed by the language itself so far even in beta form, but I really think the docs need some considerable work yet.

Erhm, definitely! The docs are very bare bones at the moment and are barely adequate - lots of information is missing. I hope he's joking.

Have you checked out the tutorial section? I know I don't focus soley on Lists but there is some examples that might come in handy I guess.

Wave : your examples are looking good and I am sure will prove very useful. The point was though that the 'official' docs are where users should expect to look first, and at present they need a lot of work.

I can't fault Mark a whole lot on the docs... They are certainly the hardest part of a programming project. Maybe not from a technical standpoint, but definitely from a mental standpoint. You spend months and months wracking your brain and fighting tooth and nail with the code... And when you are done you get this nice sense of accomplishment... only to realize you still have hours and hours and hours of tedious information to type up describing everything you just thought was finished.

The programmer is generally not the best choice to do the documentation. You get someone else to do it and use the programmer as a reference. Things that the programmer might take for granted as "a given" might be confusing or just plain not known at all to the end user. It's just a very hard thing for the programmer to also do the docs and make then as informative as a separate party entirely.

Kanati:

I agree with what you are saying about the programmer being the wrong guy to write the docs. I've been in that position myself having had to write a 700 page technical reference manual myself - 50% of which was about a programming language.

Still doesn't get away from the fact that the docs need to be some substantial work on them. Ok, so Mark is maybe not the best guy to to that, but in that case he needs to delegate the task to someone else who can look at it from a more neutral perspective.

Agree on that =)