Talk:Dynamic Storage

The arrays section actually describes matrices, or more technically arrays of arrays. As it stands, the first number is the index, the second number is the array to look up.

It might be better to suggest that the egg carton is numbered from 0-11, and that values above 5 (the 6th element) "wrap around" to the next row; that would more accurately reflect how arrays are represented in a computer. --JT 12:46, 21 May 2006 (EDT)

A matrix is just a 2 dimensional array is it not? Actually, the description uses the first number as the lookup and the second as the index. But it really is just a 2D array. It also isn't really necessary to get into how arrays REALLY work in the first page description of them. I'd almost certainly get into that in the second page when talking about how to set them up. I was just looking for a simple, real world analog to make the explaination easily understandable --Tegid 16:27, 21 May 2006 (EDT)

But my point is that you're defining a single array as "the egg carton" and then describing it as two arrays ("row 1" and "row 2"), with two independent beginnings and ends. That's many levels of wrong no matter how you present it. ;-) I think most people could easily grasp that a 12-element array translated into an egg carton would mean the 6th element would wrap to the next row for the 7th element.

In my case, I'd use a Pez container to describe an array. ;-) --JT 17:29, 27 May 2006 (EDT)

A 2D array is either a single array or multiple 1D arrays (or in reality a single 1D array with fancy math) I don't see how calling the Egg carton a single 2D array is in any way incorrect. Also, the Pez dispenser is much more akin to a Queue than to an array. --Tegid 13:22, 2 June 2006 (EDT)

The entire point of a programing language is abstraction. The reason they were created in the first place was to make it possible to write code without knowing exact details of how the system worked. Since RAM is random-access it doesn't matter how the data is stored as it always has 0 impact preformace, and while that isn't the case for other media (such as hard drives) that information is irrelevent as we aren't working with other media.

I know there's a strong desire to be thorough, but adding technical information makes it harder to read and more confusing. If somebody is reading this then either they already know what you're saying and will learn nothing anyway, or they know nothing and you need to present information which is important to them understanding it in the first place.

Also, I formatted this discussion to be more readable. Krid 17:08, 25 May 2006 (EDT)

I don't know exactly what your point is here. As a professional coder, I am well familiar with the point of languages. However, the fact is that Oblivion scripting doesn't really follow the information hiding and abstraction model. (Which really is out of the scope of a script). I attempt to abstract by giving a generic model with which to perform the desired activity. My experience in the forums has lead me to believe that many people do not even understand what I am attempting without the nitty gritty technical details. My approach is to give the technical details of how to generate a list/queue/array etc and then allow the reader to come up with the implementation specific details they desire. If someone wishes to write a "how to use a Linked List to do X," I think that would be fantastic. I hope that those that might understand it, but not without a serious explaination, will be able to use the code.

That being said, I am not at all opposed to changes to the body of the text to make it more readable/understandable, and if you have any suggestions, please let me know. Also keep in mind that this a document in progress and since I've been working long hours on the road, that progress is tending towards slower rather than faster, and I tend to spend about an hour at a time working on it. Some of your questions/comments would be addressed in the Array section that is wholey absent. --Tegid 21:52, 25 May 2006 (EDT)

You made a teensy oopsie, Krid, when you formatted this page -- I used two paragraphs in my discussion, and you indented my second paragraph. ;-) --JT 17:29, 27 May 2006 (EDT)

You implicitly excluded circular linked lists by stating that lists must have a head. Such lists would be very useful for a wide variety of things. For example, migratory NPCs which travel to predetermined places in order, as you could have the script step through a list of places. instead of having a giant loop. Krid 17:08, 25 May 2006 (EDT)

Well, first, all lists MUST have a Data Manager type of node that is a Persistent Reference in order to allow the data to be externalized. Actually that isn't TOTALLY true, but the one exception is very small. While they don't actually have to have a Head, they do need that node, and the Head is a simpler concept. I have not eliminated the possibility of the circularly linked list, especially given the Iterator model I create for the List type. Second, a circularly linked list is almost never necessary. The better solution would be an array (or index accessed list) and a mod statement. (It's simpler programmatically). --Tegid 21:52, 25 May 2006 (EDT)