TableItemArray



  • TableItem is a class.   TableItems have two instance variables, itemName and itemValue.  They are both strings.  TableItem's constructor has no parameters.  TableItems have properties to get and set their itemNames and itemValues.

    TableItemArray is a class.  TableItemArray has one instance variable, tableItems.  tableItems is an ArrayList.  TableItemArray is a singleton.  The TableItemArray has Item, Add, Remove, and Clear methods.

    Many methods use the single instance of TableItemArray for different purposes, making sure to clear it before using it.  None of them use it to share any data.  This makes threading impossible.

    Hundreds of lines of code are being replaced with a Dictionary<String, String>.

    The end...

    Or is it?



  • OMG structs!



  • I think there's already an Dictionary<string, string> equivalent in system.collections.specialized that might save you some typing.



  • @djork said:

    TableItem is a class.   TableItems have two instance variables, itemName and itemValue.  They are both strings.  TableItem's constructor has no parameters.  TableItems have properties to get and set their itemNames and itemValues.

    TableItemArray is a class.  TableItemArray has one instance variable, tableItems.  tableItems is an ArrayList.  TableItemArray is a singleton.  The TableItemArray has Item, Add, Remove, and Clear methods.

    Thought you were doing some funky metaprogramming in [url=http://www.inform-fiction.org/I7/Inform%207.html]Inform 7[/url] for a minute there.

     



  • @jcoehoorn said:

    I think there's already an Dictionary<string, string> equivalent in system.collections.specialized...

    NameValueCollection? No - he won't be able to use that probably :(
    "Public static members of this type are thread safe." - I guess, that original version had several good reasons to remove that property.

     



  • @viraptor said:

    @jcoehoorn said:

    I think there's already an Dictionary<string, string> equivalent in system.collections.specialized...

    NameValueCollection? No - he won't be able to use that probably :(
    "Public static members of this type are thread safe." - I guess, that original version had several good reasons to remove that property.

    I know you're joking, but I tried to come up with a reason one [i]wouldn't[/i] want code to be reentrant or thread-safe...

    Nope... 



  • @djork said:

    I know you're joking, but I tried to come up with a reason one [i]wouldn't[/i] want code to be reentrant or thread-safe...

    Nope... 

    Are people stupid around here? Obviously the coder *wanted* the application to crash at random. Sheesh!



  • @DaEagle said:

    @djork said:

    I know you're joking, but I tried to come up with a reason one [i]wouldn't[/i] want code to be reentrant or thread-safe...

    Nope... 

    Are people stupid around here? Obviously the coder *wanted* the application to crash at random. Sheesh!

    But that's why there are dozens upon dozens of explicit thread-juggling calls to Thread.Sleep(0) and Application.DoEvents... it's all good :)



  • @djork said:

    @viraptor said:
    NameValueCollection? No - he won't be able to use that probably :(
    "Public static members of this type are thread safe." - I guess, that original version had several good reasons to remove that property.

    I know you're joking, but I tried to come up with a reason one [i]wouldn't[/i] want code to be reentrant or thread-safe...

    Nope...

    There are at least two reasons for not adding full thread safety for classes. It adds complexity to the code and it adds performance overhead. If you only use a collection from a single thread, there's absolutely no need to protect it with semaphores. 

    Another reason is that some things are hard to make thread safe at the class level in a usage neutral way. I'm thinking of things like iterating over a collection which, depending on usage/implementation, you can't protect inside the enumerator. You have to do it in the function that is actually iterating over it.



  • @djork said:

    Hundreds of lines of code are being replaced with a Dictionary<String, String>.

    The end...

    Or is it?

    Maybe I'm being a little dense;, however, if there is no reason for the class to be a singleton, wouldn't the simplest solution be to remove that from the class?  Thereby, every one of your calls to new TableItemArray() would indeed create a separate instance and therefore be thread safe?

    Just saying...


Log in to reply