var/Listy[0][0]
for(var/i=1,i<=3,i++)
Listy.len++
Listy[i]=new /list
But this doesn't:
var/Listy[0][0]
for(var/i=1,i<=3,i++)
Listy+=new /list
Just curious.
ID:151747
 Jun 5 2009, 1:21 am
|
|
Why does this work:
But this doesn't: Just curious. | |
Kaioken wrote:
So what the 2nd method does is, add all elements in an empty list to another list (== do nothing). Makes sense. Thanks. | |
If you want it to all be in one line, try:
Listy[++Listy.len]=new/list
| |
AJX wrote:
Listy.len++ I probably wouldn't do this. Assuming we're using the /list type built into DM, the .len value is a tracker of the length of the list that is updated automatically as new elements are added to it. If you're incrementing the list, you're basically just trying to mess with the tracker. DM is a friendlier language than to require you allocate the space in a list before using it. Assuming we're talking about a pre-existing list that has already been initialized, just stick the new element in there with .Add() or += and away you go. | |
Geldonyetich wrote:
AJX wrote: This is a friendly language until you get into the realm multi-dimensional lists, and then it stops being so friendly. | |
AJX wrote:
This is a friendly language until you get into the realm multi-dimensional lists, and then it stops being so friendly. I stand corrected. Clearly, I haven't dabbled much with that particular morass. | |
Geldonyetich wrote:
AJX wrote: Anyway, this topic has already long since been answered. Nao just felt like answering a question that wasn't asked... | |
Geldonyetich wrote:
I probably wouldn't do this. Yes, for conventional purposes you wouldn't need this. But it helps to actually read the topic and consider the context before determining whether you would or not do this, and especially, before replying. ;) the .len value is a tracker of the length of the list that is updated automatically as new elements are added to it. If you're incrementing the list, you're basically just trying to mess with the tracker. No, modifying the len causes the list to be updated accordingly as well (List.len++ is equivalent to List += null), and it changes to have the number of elements specified. If modifying this var was actually screwy, it would've simply been read-only (common sense in action) - you're meant to modify it. DM is a friendlier language than to require you allocate the space in a list before using it. In this case, the friendliness of the list item-adding methods actually causes you to need to use this workaround, heh. Assuming we're talking about a pre-existing list that has already been initialized, just stick the new element in there with .Add() or += and away you go. If you had read the the topic, you would've noticed that you can't use Add() or += to add a list reference [to another list], so setting the reference directly into an existing position in the list was required. | |
Kaioken wrote:
Geldonyetich wrote: I find this an ironic admonishment seeing how a little reading would have revealed to you that I've already acknowledged that. I do appreciate the additional information in regards to the specifics, however. | |
Geldonyetich wrote:
I find this an ironic admonishment seeing how a little reading would have revealed to you that I've already acknowledged that. Not that it actually matters whether you've acknowledged it or not, but I can't even find that. Where? Was saying "I don't have experience with multidimensional lists" supposed to mean "Oops, I haven't actually read the topic before replying", or what? Perhaps you didn't understand (or read...); my statement was in reply to you basically saying "don't increase len of the list, just use Add()" when this entire topic was about the subject of Add() not working for this purpose. I do appreciate the additional information in regards to the specifics, however. Happy to inform, though I didn't reveal anything not in the DM Reference; so you may just find it handy if you appreciate info. | |
Kaioken wrote:
Geldonyetich wrote: Unless it is possible to both admit your ignorance on a subject while implying it was justified to have posted, then yes, I thought that "oops, I was ignorant and shouldn't have posted" was implied. That you keep pointing this out as a reading problem tells me that your admonishment is ironic. Though this isn't the first time you've chastised me over this (the last time was not 100% justified either in that you were taking me completely out of context) the truth of the matter is I'm better at taking the time to read than most. However, being human, mistakes will happen regardless. You see, when I said "I probably wouldn't do this," you shouldn't have read "you can't do this." What I was saying was that I prefer not to manipulate .len directly. Even if I had never manipulated .len directly, it was a fair assumption you could because the original poster wasn't complaining it wasn't letting him. This is, after all, the "Design Philosophy" forum, not the "Code Help" forum, so I was merely expounding on my design philosophy. I went on to say that (unlike some languages I've tinkered with) DM was friendly enough not to necessitate manual .len manipulation, so I prefer to let DM keep track of its list object lengths itself. In my mind, this would be a safe coding practice, as adding a null entry to the list may prove problematic. For example, if you forget to put something in that null increment and then run it through a routine that doesn't know how to handle null values in that list. Thus, I would prefer to have real information in my lists, even if that information is a placeholder. When I was told that multidimensional arrays would require the manipulation of .len directly, I stood corrected: it was no longer a matter of design philosophy, but rather necessity. The misunderstanding was not born from lack of reading (because not even the DM reference mentions this) but rather from an idiosyncrasy in the way DM does multidimensional lists. I likely would have had to discover by experimenting with them myself before finding the necessity to search resources for an answer (assuming I found the necessity to use a multidimensional list in an object oriented language). Hence, the irony of your admonishment: you actually ended up assuming more about what I wrote than I did about anything I read here! ;) I would have explained this better before, but I thought it would make less waves if I simply gracefully withdrew as being ignorant. Putting me on the spot after resolution was already done made that policy infeasible. | |
The ability to change the .len var manually is not a burden, but a useful feature. You should not be afraid to use it, given you have the proper knowledge to implement it correctly. It's the same with all programming techniques. Since you mentioned a specific example, such as a program that wouldn't know how to handle null in a list, you have ironically already stated a fix to your problem. Just make it so that the program does know how to handle null, or make it so that as soon as the .len var is increased, change the new value to something not null. (Such as exactly what we've already shown you.)
Also, he's (AJX is) right, you know. I just decided to throw in my 2¢ after the topic had already been solved. | |
Naokohiro wrote:
The ability to change the .len var manually is not a burden, but a useful feature. You should not be afraid to use it, given you have the proper knowledge to implement it correctly. It's the same with all programming techniques. Sure. However, what I was speaking about was design philosophy preference, not technical ability. Since you mentioned a specific example, such as a program that wouldn't know how to handle null in a list, you have ironically already stated a fix to your problem. Just make it so that the program does know how to handle null, or make it so that as soon as the .len var is increased, change the new value to something not null. (Such as exactly what we've already shown you.) As a paranoid coder, I do this constantly already, probably in a lot of places where I don't need to do it. (For example, I'll tend to throw in null checks in every single proc I wrote as applies to the args... but if I'm the only one using those procs, I'm essentially bloating up my code by protecting me from myself.) However, in the particular case of lists, my thinking is that null checking routines compromise the code by throwing in a whole lot of bloat. For example, if you're running through a 2000 member list and stick in an if (null) statement, that's 2000 extra evaluations you could have avoided by simply making the presence of a null in the list impossible. | |
Hierarchical state machine design patterns really lend themselves to these kinds of scenarios, where-by you encompass your list in a datum which controls access and maintains consistency of the list, streamlining your most commonly used list functionality (typically data access and enumeration). I'll leave hierarchical FSM design to the reader's discretion, but it's essentially all about going design by contract to save error checking redundancy.
| |
Geldonyetich wrote:
As a paranoid coder, I do this constantly already, probably in a lot of places where I don't need to do it. (For example, I'll tend to throw in null checks in every single proc I wrote as applies to the args... but if I'm the only one using those procs, I'm essentially bloating up my code by protecting me from myself.) For a little while, I thought this was a good idea. But then I actually thought about it: if the proc is being called with invalid arguments, then it SHOULD crash. After all, that means something is wrong, and I'd rather know WHERE it went wrong rather than scratching my head wondering what caused things to be slightly off. So generally, I'll save that kind of "error checking" only for cases where it would actually be accepted behavior (and is, therefore, not an error). Or, I guess, if you want to output a more explicit error message. | |
I kind of figured he was already doing that, but it's definitely a good point to note for other readers. Typically I will perform sanitary checks like that for the sake of CRASH()ing a more useful message close to the point of error. I'm not a huge fan of letting null errors propagate down a call-stack because I was just passing arguments through to other procs.
| |
So what the 2nd method does is, add all elements in an empty list to another list (== do nothing).
The first method directly sets a value in a specific index in the list, no questions asked, so it works in setting a /list reference.