Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
Ok I'm not sure how viable this is, but how it currently works is that if a reference in a list goes missing, null is left at that index in the list and the length of the list stays the same.

How I thought it worked for a long time (til I found out otherwise recently), and how I would like for it to work, is that if a reference in the list goes missing, it is removed from any lists that contain it, and the list would be shortened by 1 upon its removal.

In the case of my game, the list is filled with mobs. It is the global Player_List. The game loops thru it constantly and frequently for different reasons. I recently found out that every time a player logs out a null reference is left behind in the list and the length stays the same. So I would for example have 30 players online, and 1000 nulls in the list, making the length of the list 1030.

So I was looping thru 1030 entries instead of just 30 entries, causing a lot of lag. I had to make my own function called Remove_nulls(list/L) which just returns a new list without the nulls and assigns it to the old one. This is really inconvenient to have to do in so many places.

Am I just doing something wrong? Or could you guys make it so when a mob deletes all lists that reference it are shrunk by 1? (No null references would be left in the list)

Thanks. Although in what context is Lummox Jr saying to use while(list.Remove(null)) ?
That would remove all null values in the list.

You're better off just not letting it happen in the first place. Remove the player's mob from the list before you delete it.
The problem with shortening is you have then altered the indexes of the other elements, which might be indexes the developer is relying on, for one reason or another.
Yes but there could be something like world.list_mode=you_know_whatever default it would be the old mode.
Ter13 resolved issue (Redundant)

Largely, this feature would cause conflicts with existing behavior. If you are maintaining a list of objects that should remain current, you are going to need to accommodate that with soft-code.
The problem with that is basically maintainability. Imagine if you will, what happens when we get developer help posts where people are forceably deleting objects, and are getting some odd behaviour further on which they want help with.

The language semantics change significantly, and the helper (and other developers) then have to establish that, on any list related question, before getting to the actual issue they need help with.

Similarly, you could certainly set the setting, but the entire base of libraries available on the site do not take into account that setting, so you are going to do yourself a terrible dis-service by way of obscure bugs in what everyone else has tested and verified as solid, usable library code.