From: Stephen E. <ed...@cs...> - 2006-11-29 19:28:27
|
Anjo Krank wrote: > or come up with something that can actually > solve this load.order problem (hardest:) It this really that hard? It seems like all of the following will accomplish this goal, with differing tradeoffs: 1) Refactor the static boolean field so that it is a local variable inside _checkEditingContextDelegate(). This would cause the lookup to be performed on each call. You can tuck the lookup inside the if statements to avoid this cost when it isn't needed. This would avoid the problem of caching too early, and would add the benefit that the setting can now be dynamic (maybe relatively worthless, but still a benefit :-)). 2) If the cost of the lookup is too much, then refactor the static field to create an accessor around a lazily initialized Boolean field. This would mean changing the reads of the field in the static method into accessor calls. The accessor could check for null on first access, perform the lookup at that point, and cache the value so the lookup cost is only paid once. This delays the caching until first use, as opposed to class load time, but only performs the lookup once. 3) If the overhead of using an accessor call each time the field value is needed is too high, you can still use a Boolean field and perform the check for null/lazy initialization once, inside _checkEditingContextDelegate(), and then directly access the field from there on out. This would eliminate a few method calls and null checks, at the expense of making the code slightly more brittle. All of these involve the key idea of delaying the property lookup until after code is running, rather than doing it in what amounts to a static initializer. Shouldn't that fix the load order problem? -- Steve -- Stephen Edwards 604 McBryde Hall Dept. of Computer Science e-mail : ed...@cs... U.S. mail: Virginia Tech (VPI&SU) office phone: (540)-231-5723 Blacksburg, VA 24061 ------------------------------------------------------------------------------- |