Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

[brett l. <bre...@gm...>]

On Sat, Jul 23, 2011 at 8:56 AM, Erik Vos <eri...@xs...> wrote:
>
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Saturday, July 23, 2011 5:36 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8)
>> To be clear, the thing I was trying to recommend against is *just* the
>> configureFromXML() method that we typically use to initialize the *Manager
>> classes.
>>
>> That's the biggest point where a client/server model will differ.
>
> Why?
> The client won't have the same managers, but why can't whatever will replace the managers call the same configureFromXML() methods of the objects that they need to know about?
>

Because the clients should take the "authoritative" values for things
given to it by the server, not whatever arbitrary values somebody
decides to put into their own local XML files. Trusting the client to
do the right thing on its own makes exploitation far too easy.

>> We'll need to instantiate the various *Manager classes, but those classes will
>> need to be instantiated using normal constructors that can then be
>> configured, probably by getters and setters to allow the method of obtaining
>> the information to be either local or remote, and the "game engine" won't
>> care which.
>
> Always local, in my concept.  Static info does not need to squeezed through the client/server interface.
> Unless you want to make the client really dumb, of course.  And slower.
>

Over-use of static info also makes supporting multiple threads more
problematic; it increases the likelihood of race conditions and other
difficult-to-debug issues. In general, most of the stuff that's
currently static doesn't really _need_ to be static.

> Erik.
>
>> So, my main point is that I'd like us to be conscious of which classes have
>> awareness of lower-level information (like XML parsing) and ensure that
>> knowledge is appropriately abstracted away from the game logic in the same
>> way that we try to separate the game logic from the display/view logic.
>>
>> ---Brett.
>

---Brett.