Talk:FriendPackages

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Improvement suggestions)
Line 1: Line 1:
Accessor could perhaps be called ItemAccessor (living in ItemAccessor.java)? This makes it more obvious that you have to write this boilerplate for each class needing the back door. TBa
Accessor could perhaps be called ItemAccessor (living in ItemAccessor.java)? This makes it more obvious that you have to write this boilerplate for each class needing the back door. TBa
 +
 +
* JST: Actually once per package is enough.
It would be nice to be able to put in extra comments without cluttering up the text. Hovers would be ideal, but I guess not supported by this Wiki (and not in the code section anyway). Is there any way of doing footnotes? The particular point is the line l = listener in Item.java. This is presumably so that in the presence of multiple threads, an "obslete" listener may be called, but you will never get a null pointer exception. That's too much to clutter the code with, but it spent quite a bit of my effort working it out. TBa
It would be nice to be able to put in extra comments without cluttering up the text. Hovers would be ideal, but I guess not supported by this Wiki (and not in the code section anyway). Is there any way of doing footnotes? The particular point is the line l = listener in Item.java. This is presumably so that in the presence of multiple threads, an "obslete" listener may be called, but you will never get a null pointer exception. That's too much to clutter the code with, but it spent quite a bit of my effort working it out. TBa
Should all the "default"s really be called "default"? aren't we really talking about TheAccessor or something? TBa
Should all the "default"s really be called "default"? aren't we really talking about TheAccessor or something? TBa
 +
 +
* JST: [[NetBeans]] usually call singleton returning methods getDefault(). Having symetric setDefault(...) is appropriate, I guess.
It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized? TBa
It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized? TBa
 +
 +
* JST: The classloading trick is still there, I just moved it outside of the code snippets. Just click on the name of the source file above each code snippet.
 +
** It is only necessary if someone uses Accessor first without Item being loaded (e.g. which is only possible while calling constructor, I guess)
 +
** Otherwise the setDefault is still being called from static { ... } initializer and as such it is synchronized on the Item class.
 +
** I might try to put a guard in constructor of Accessor:
 +
<source lang="java">
 +
protected Accessor() {
 +
if (!getClass().getName().equals("api.AccessorImpl")) {
 +
throw new IllegalStateException();
 +
}
 +
}
 +
</source>
 +
and then the need for synchronization would be completely gone.

Revision as of 16:47, 24 October 2008

Accessor could perhaps be called ItemAccessor (living in ItemAccessor.java)? This makes it more obvious that you have to write this boilerplate for each class needing the back door. TBa

  • JST: Actually once per package is enough.

It would be nice to be able to put in extra comments without cluttering up the text. Hovers would be ideal, but I guess not supported by this Wiki (and not in the code section anyway). Is there any way of doing footnotes? The particular point is the line l = listener in Item.java. This is presumably so that in the presence of multiple threads, an "obslete" listener may be called, but you will never get a null pointer exception. That's too much to clutter the code with, but it spent quite a bit of my effort working it out. TBa

Should all the "default"s really be called "default"? aren't we really talking about TheAccessor or something? TBa

  • JST: NetBeans usually call singleton returning methods getDefault(). Having symetric setDefault(...) is appropriate, I guess.

It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized? TBa

  • JST: The classloading trick is still there, I just moved it outside of the code snippets. Just click on the name of the source file above each code snippet.
    • It is only necessary if someone uses Accessor first without Item being loaded (e.g. which is only possible while calling constructor, I guess)
    • Otherwise the setDefault is still being called from static { ... } initializer and as such it is synchronized on the Item class.
    • I might try to put a guard in constructor of Accessor:
protected Accessor() {
  if (!getClass().getName().equals("api.AccessorImpl")) {
    throw new IllegalStateException();
  }
}

and then the need for synchronization would be completely gone.

Personal tools
buy