127 reputation
6
bio website voodooshader.com
location Minneapolis, MN
age 22
visits member for 3 years, 8 months
seen Apr 8 at 13:59

I'm a pretty general developer working in Java and Javascript web applications for a wellness company during the day, while specializing in low-level graphics and overhauling old applications by night.


Aug
22
accepted What other patterns can I use for this singleton?
Aug
22
awarded  Critic
Aug
22
awarded  Scholar
Aug
14
awarded  Autobiographer
Feb
16
awarded  Commentator
Feb
16
comment What other patterns can I use for this singleton?
I do think you're onto something with the tuple idea and 4, potentially with a global variable dictionary instead of a global parser.
Feb
16
comment What other patterns can I use for this singleton?
The log messages are formatted as-needed, so if the Logger can early-out based on severity level, the format will never occur, otherwise the format is triggered, then a brief lock for atomic write. What I do want is for all the log info from a single run of a single process to go into a single file, for a variety of reasons which include 6. Most logging only happens during error handling, at which point performance is tenth concern to in-order logging (stamped to the ms), making sure the log makes it to disk (the log is flushed if an error is logged), and so on.
Feb
16
comment What other patterns can I use for this singleton?
For 2, any plugin or most others bits of code may access the Server in order to create objects or load other plugins, but there must never be competing servers, hence the use of a singleton. I am well aware of all the implications of the (anti-)pattern, but that object is the ideal use case for it. For 3 , the Parser is also available to any plugin and at any time, but (4) it is Core-specific, so trying to move it there will likely help. For 5, the singleton creation and all calls are thread-safe (all the objects and their methods are, in fact)...
Feb
16
comment What other patterns can I use for this singleton?
@jhocking Singletons aren't innately bad, there is a very valid use case for the pattern, and the Server is it: all the state it governs is process-specific but must be accessible anywhere within the process and there must never be more than one instance. Making it anything else complicates a lot of things. The "start point" is the creation of a core.
Feb
16
awarded  Student
Feb
16
comment What other patterns can I use for this singleton?
@RaySaltrelli Where do the Server Logger and Parser get their information? Cores will need to share variables with the Server's Parser, a path from the configuration file, for example (with some good reasoning, that could probably be removed). I certainly don't want to log to multiple places, that would make a bug-reporting nightmare.
Feb
16
comment What other patterns can I use for this singleton?
@RaySaltrelli That's a possible solution. At the moment, only the first configuration is used; for example the Core does if (!Logger.IsOpen) Logger.Open() and so on. While the Parser and Logger as singletons is useful for a variety of reasons, it restricts them to single configurations, which is the problem that caused me to reevaluate using singletons.
Feb
16
comment What other patterns can I use for this singleton?
@jhocking Why? What benefit does that provide over the current model? Having a singleton that creates, holds and passes instances vs having each object be a singleton gives the same end behavior.
Feb
16
comment What other patterns can I use for this singleton?
@RaySaltrelli That one of the problems in one of my ideas, not the current state of affairs. At the moment, the Logger and Parser are also singletons, with some finalization done when a Core is created (adding of variables and such). If the Server was to get its own instances, then the data source would become an issue.
Feb
16
asked What other patterns can I use for this singleton?
Jul
14
comment What do you do when you have nothing to do?
Stackexchange is up there with Wikipedia and TVTropes for time killing.
Mar
26
comment Do software engineers really need to know low level stuff anymore?
To add my 0.02, knowing how something is done when you demand it happen is usually a good thing. Can help make your demands more reasonable and efficient (applies to high-level programming and maybe bosses ;)).
Nov
2
awarded  Supporter