Name Refactoring

[Spartan322]

This issue pertains to names we have yet to refactor and are or should consider for refactoring. Please post refactoring suggestions below.

This list will stay open perpetually as long as refactoring for naming is considered.

Currently:

• SaveLoaderReplacement, ContentLoaderReplacement, ReplacementCommons into new Replacement namespace (Add ActionsLoader Replacement #27)
• SaveLoaderReplacement:LoadFaction -> ReplacementCommons:LoadFaction
• ContentLoaderReplacement -> ComputerLoaderReplacement
• Game.OS.Extensions:Write -> WriteLine (12ea319)
• Game.OS.Extensions:WriteSingle -> WriteAppend (12ea319)

[Spartan322]

Put SaveLoaderReplacement and ContentLoaderReplacement into a Replacement namespace and remove Replacement from their name.

Add more methods to ReplacementCommons, and put it in the Replacement namespace for dual applicable functionality which still needs to include:

• SaveLoaderReplacement:LoadFaction

[Fayti1703]

• ContentLoader(Replacement) to ComputerLoader(replacement)

Debatably:

• SaveLoader:LoadComputer -> ComputerLoader:LoadFromSave?

[Spartan322]

@Fayti1703 I think it probably be better to keep the save loading in a separate class since we have to treat it differently already and it would really bunch up the ComputerLoader class, and I think it be easier to understand there are distinctions of hooking into save loading and computer loading. (even though we do need to keep track of content and saves when loading them) Unless we separate the replacement loading methods from the hook in functionality, perhaps we could also create classes for the Internal SaveHooks and ComputerHooks that take the place of directly loading anything in the load methods.

[Spartan322]

• Game.OS.Extensions.Write -> WriteLine
• Game.OS.Extensions.WriteSingle -> WriteAppend

[Spartan322]

Suggestions:

• EventExecutor -> XmlFragmentParser
• ParsedTreeExecutor -> XmlElementParser
• IExecutor -> XmlSegementParser (turn into a class that XmlFragmentParser and XmlElementParser will both derive from)
• EventReader -> ? (any suggestions on new name or removal/replacement)

[Arkhist]

I totally agree with the suggestions.
As for "EventReader", I don't know :/

[Spartan322]

Perhaps the best option would be to remove EventReader, add everything in it to XmlFragmentParser instead, we have no reason to separate them anyway and it doesn't change how anything is built otherwise.