'. '

Talk:FriendPackages

From APIDesign

(Difference between revisions)
Jump to: navigation, search
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
+
Comments by Tim Band (''TBa'').
-
* JST: Actually once per package is enough.
+
* ''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
+
* ''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?
 +
* ''JST'': This is [[wikipedia::mediawiki]] and it has a lot of extensions. More than I know about.
-
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.
+
* ''TBa'': The particular point is the line l = listener in Item.java. This is presumably so that in the presence of multiple threads, an "obsolete" 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.
 +
* ''JST'': The current code is not really multithreaded.
-
It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized? TBa
+
* ''TBa'': Should all the "default"s really be called "default"? aren't we really talking about TheAccessor or something?
 +
* ''JST'': I am not sure I get the comment, but [[NetBeans]] usually call singleton returning methods getDefault(). Having symmetrical setDefault(...) is appropriate, I guess.
-
* 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.
+
* ''TBa'': It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized?
-
** It is only necessary if someone uses Accessor first without Item being loaded (e.g. which is only possible while calling constructor, I guess)
+
* ''JST'': The classloading trick is still there, I just moved it outside of the code snippets. 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" snippet="design.less.friend.InitAPI"/>
-
<source lang="java">
+
 
-
protected Accessor() {
+
* 'JST': It might be possible to to put a guard in constructor of Accessor just like in this example:
-
if (!getClass().getName().equals("api.AccessorImpl")) {
+
<source lang="java" snippet="forjoe.InterfaceThatJustJoeCanImplement"/>
-
throw new IllegalStateException();
+
-
}
+
-
}
+
-
</source>
+
-
and then the need for synchronization would be completely gone.
+

Revision as of 19:30, 24 October 2008

Comments by Tim Band (TBa).

  • 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.
  • 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?
  • JST: This is wikipedia::mediawiki and it has a lot of extensions. More than I know about.


  • TBa: The particular point is the line l = listener in Item.java. This is presumably so that in the presence of multiple threads, an "obsolete" 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.
  • JST: The current code is not really multithreaded.
  • TBa: Should all the "default"s really be called "default"? aren't we really talking about TheAccessor or something?
  • JST: I am not sure I get the comment, but NetBeans usually call singleton returning methods getDefault(). Having symmetrical setDefault(...) is appropriate, I guess.
  • TBa: It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized?
  • JST: The classloading trick is still there, I just moved it outside of the code snippets. It is only necessary if someone uses Accessor first without Item being loaded (e.g. which is only possible while calling constructor, I guess):
Code from Accessor.java:
See the whole file.

private static final Class<?> INIT_API_CLASS = loadClass(
    Item.class.getName()
);
private static Class<?> loadClass(String name) {
    try {
        return Class.forName(
            name, true, Accessor.class.getClassLoader()
        );
    } catch (Exception ex) {
        throw new RuntimeException(ex);
    }
}
 
  • 'JST': It might be possible to to put a guard in constructor of Accessor just like in this example:
Code from InterfaceThatJustJoeCanImplement.java:
See the whole file.

public abstract class InterfaceThatJustJoeCanImplement {
    protected InterfaceThatJustJoeCanImplement() {
        if (!"impl.joe.JoesImpl".equals(getClass().getName())) {
            throw new IllegalStateException(
                "Sorry, you are not allowed to implement this class"
            );
        }
    }
 
    public abstract void everyoneCallThisJoeWillHandleTheRequest();
}
 
Personal tools
buy