Ticket #33 (closed task: wontfix)

Opened 1 year ago

Last modified 10 months ago

Static Constructor

Reported by: clayasaurus Assigned to: clayasaurus
Priority: major Milestone: 0.3
Component: unspecified Version: svn
Keywords: Cc: ChristianK

Description

Make use of static constructors once .di import bug is fixed.

See http://www.dsource.org/forums/viewtopic.php?t=2578&postdays=0&postorder=asc&start=15

for more details about the problems and solution of static constructors.

Change History

05/02/07 13:59:44 changed by clayasaurus

  • owner changed from ChristianK to clayasaurus.
  • type changed from defect to task.

06/01/07 02:22:02 changed by ChristianK

This is the bug to watch: http://d.puremagic.com/issues/show_bug.cgi?id=668

07/22/07 07:05:30 changed by ChristianK

The current open/close methods have a significant problem: if you forget to call open, you get no proper error message, but a generic access violation / segfault. I think these are options

  • static ctors, once the D bug is fixed (my prefered solution)
  • singletons (overkill, clunky)
  • prefixing every method with a check to see if open() has been called. (annoying)

07/23/07 03:20:02 changed by ChristianK

The static this order bug has been fixed! This might be worthwile backporting to 0.2...

07/23/07 04:25:11 changed by ChristianK

  • cc set to ChristianK.

With this out of the way, I feel it would be best to remove all open/close functions and replace them with static con-/destructors. I don't think there's a disadvantage with calling these automatically now that the order is guaranteed to be correct. There are several advantages

  • no weird bugs from forgetting to open() a subsystem
  • user code gets shorter
  • if the modules must be initialized in a certain order, it'll work automatically
  • user code can allocate resources (load textures etc.) in static constructors

The only open and close function that should stay is the one for arc.window - it just makes sense there. However, it should only deal with window open/close, the derelict init should go into a static constructor too.

07/23/07 04:53:24 changed by ChristianK

Sorry about not putting all this in one message... :)

There is a disadvantage: error handling. We can not catch any exceptions thrown by static constructors. The options I see here are

  • beg Walter to allow customizing the default exception handler (unlikely to have an effect any time soon)
  • on error: write to log file, set some initialized variable to false, continue as if nothing happened (annoying, as it will effectively replace the open() calls with error checking code; but at least there's a log message about things going wrong)
  • keep things with recoverable errors in open()-like functions (might be best)

My current opinion is that all the derelict init can go into static constructors (the program couldn't recover from an error there anyway). Same for everything else that's non-recoverable. However, things like the sound system initialization, which are non-fatal and possibly recoverable, should stay in open().

10/01/07 11:06:56 changed by ChristianK

  • status changed from new to closed.
  • resolution set to wontfix.

I've experimented with it a bit and my opinion is that we should leave things as they are. Putting the derelict and SDL initializations into static constructors makes errors harder to catch and doesn't seem to yield any significant benefits. In particular, you still can't construct texture objects in static constructors since the OpenGL context is not yet up.

Instead, I've added a signal to arc.window that is raised when a window is opened.

I'd still prefer it if there was a sensible error message if someone forgets to call an open(), but see no good way to do that without moving all our functions inside of a struct or class.