Rewrite Static Stateful Classes #180

New Issue

2014-07-15T19:11:33Z

SenseiKiwi commented

2014-07-15 19:11:33 +00:00

(Migrated from github.com)

I'd like to recommend a change that could save us some pain in the long run, although I'm not sure of whether we would want to do this before the move to MC 1.7. We have some critical classes such as mod_pocketDim and PocketManager that are static but also have state information. That's problematic because of issues like state leaking from one game session to another, and it stops us from have seamless specialized classes for client-only and server-only interactions. We should move away from that:

Stop using static fields in mod_pocketDim for every last thing. Use instance fields and require accessing the mod's instance.
Move related fields, such as items and blocks, into their own respective singletons (e.g. DDBlocks, DDItems), along with their initialization code.
Store session-related fields in a separate object with an unload() method to make sure they're cleaned up when a session ends, and to prevent other code from referencing fields that have expired.
Rewrite PocketManager as a regular class. Declare an interface or abstract base class and create subtypes specifically for client-side or server-side use. This would prevent all sorts of problems, such as trying to save dimension data on the client side, or raising dimension or link events on the client.

I'd like to recommend a change that could save us some pain in the long run, although I'm not sure of whether we would want to do this before the move to MC 1.7. We have some critical classes such as mod_pocketDim and PocketManager that are static but also have state information. That's problematic because of issues like state leaking from one game session to another, and it stops us from have seamless specialized classes for client-only and server-only interactions. We should move away from that: 1. Stop using static fields in mod_pocketDim for every last thing. Use instance fields and require accessing the mod's instance. 2. Move related fields, such as items and blocks, into their own respective singletons (e.g. DDBlocks, DDItems), along with their initialization code. 3. Store session-related fields in a separate object with an unload() method to make sure they're cleaned up when a session ends, and to prevent other code from referencing fields that have expired. 4. Rewrite PocketManager as a regular class. Declare an interface or abstract base class and create subtypes specifically for client-side or server-side use. This would prevent all sorts of problems, such as trying to save dimension data on the client side, or raising dimension or link events on the client.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: apex/DimDoors#180