JaroslavTulach: Talk:APIDesignPatterns:FriendPackages moved to Talk:FriendPackages - 2008-11-15 12:38:46

Talk:APIDesignPatterns:FriendPackages moved to Talk:FriendPackages

←Older revision Revision as of 12:38, 15 November 2008

JaroslavTulach at 09:29, 25 October 2008 - 2008-10-25 09:29:23

←Older revision Revision as of 09:29, 25 October 2008
Line 2: Line 2:
* ''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
* ''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.
+
* [[User:JaroslavTulach|''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?
* ''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.
+
* [[User:JaroslavTulach|''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.
* ''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.
+
* [[User:JaroslavTulach|''JST'']]: The current code is not really multithreaded. As far as the initialization goes, it shall not matter, as it is expected that the ''setDefault'' method is part of implementation not API and as such it will be called just once.
* ''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?
-
* ''JST'': I am not sure I get the comment, but [[NetBeans]] usually call singleton returning methods getDefault(). Having symmetrical setDefault(...) is appropriate, I guess.
+
* [[User:JaroslavTulach|''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?
* ''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):
+
* [[User:JaroslavTulach|''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):
<source lang="java" snippet="design.less.friend.InitAPI"/>
<source lang="java" snippet="design.less.friend.InitAPI"/>

JaroslavTulach at 19:30, 24 October 2008 - 2008-10-24 19:30:20

←Older revision Revision as of 19:30, 24 October 2008
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.
+

JaroslavTulach at 16:47, 24 October 2008 - 2008-10-24 16:47:59

←Older revision Revision as of 16:47, 24 October 2008
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.

TimBand: Improvement suggestions - 2008-10-24 13:21:00

Improvement suggestions

New page

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

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

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