TNet.List

[larryapple]

I am using Lists extensively throughout my turn-based cribbage game, and would like to use RFC's directly in my top-level game manager script so that when in single-player mode vs. "the computer", the computer algorithms can call the RFC's as if the play came from a remote player. I also have several utility scripts that pass these lists back and forth.

TNet has made a new version of the List function in order to avoid excess memory usage. So now every reference to these lists is ambiguous unless I qualify it by TNet.List, and include "using TNet" in every script. This violates my desire to keep inter-class dependencies to a minimum, and keep the code clean. Is there a way to avoid this without introducing another level of calls without RFC?

[tehshawn]

You can add "System.Collections.Generic" in front of your Lists if you want to avoid using the TNet version and clear the ambiguous reference warning.

I admit I found this to be a slight inconvenience as I had to add a bunch of these since I did not require the added efficiency that the TNet one had to offer. In addition I often supplement my list usage with LINQ extension methods, which the TNet one doesn't currently have. Perhaps a refactor of the TNet.List class name may be the nicest solution?

[ArenMook]

TNet's list is in a namespace, so unless you explicitly state "using TNet" as well as "using System.Collections.Generic", you won't have any ambiguity.

Generic list is a memory-unfriendly class. I dropped using Generic.List in favor of TNet.List a long time ago (called BetterList in NGUI). I also recommend never using foreach syntax, as it causes allocations you can easily avoid by having a simple for loop. I personally don't use LINQ so can't comment on it as far as memory management goes.

[larryapple]

I am passing these lists as parameters to other scripts that do not use TNet, so I would think that the same name for two classes implemented differently would be a problem or at least an inconsistency. It would seem to me that the NGUI class with the different name, BetterList, is a better solution than TNet.List. So thanks, I am now using BetterList.

[nah0y]

TNet's list is in a namespace, so unless you explicitly state "using TNet" as well as "using System.Collections.Generic", you won't have any ambiguity.

I have this exact problem... I'm using both TNet and System.Collections.Generic, and that's a pain in the ass to add TNet. in front of everything :/
Can't you rename it to BetterList or TNetList ?


I know you'll say no, but we never know

[ArenMook]

What's the difference between typing TNetList or TNet.List?

Furthermore you can add this to the top of the file:

1. using List = TNet.List;

[nah0y]

Ah yes! Forgot about the trick using List = TNet.List; thx!


The difference is that using TNet.List, if you also import System.Collections.Generic, the compiler do not know if you're using TNet.List or System.Collections.Generic.List and send you an error. Using TNetList will not have this.

But I'll use using List = ...

[nah0y]

Hum.... seems like you can't do :
using List = TNet.List


You have to do using List = TNet.List<string> for example.
And what if you have multiple list type? :/

[ArenMook]

Typing the whole "TNet.List" clarifies the namespace, which is what I was suggesting. I was asking how it differs from typing "TNetList". Just a single character. It's hardly worth renaming an entire class and breaking backwards compatibility of all projects for.

[nah0y]

Yes, yes, but the thing is, I don't want to use TNet.List, but System.Collections.Generic.List, and typing that inside the code is kind of ugly