This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Minor generification problems in AbstractLookup.Pair | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Lookup | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | apireviews |
Priority: | P3 | Keywords: | API |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 67888 | ||
Attachments: | Fix for the Lookups.lookupItem, I do not think the first problem is valid however |
Description
Jesse Glick
2006-04-04 02:23:11 UTC
Created attachment 29579 [details]
Fix for the Lookups.lookupItem, I do not think the first problem is valid however
I fixed the Lookups.lookupItem part: openide/util/src/org/openide/util/lookup/Lookups.java,v <-- Lookups.java new revision: 1.4; previous revision: 1.3 As concern the Pair signature, I do not think so. Basically I can call the methods with any object or class without knowing the T. The case of creatorOf might be similar to Collection.remove(Object). However I am not 100% sure. I disagree: Pair<T> is subclassing Item<T> and does not even use its type parameter at all! Also look at SimpleLookupTest to see why the current situation is painful: protected boolean creatorOf(Object obj) { // item.getInstance :: T, so why Object? return item.getInstance() == obj; } and public Class<? extends T> getType() { return item.getType (); } @SuppressWarnings("unchecked") // ! protected boolean instanceOf(Class c) { return c.isAssignableFrom(getType()); } The lookupItem patch seems to work well. It is possible that instanceOf(Class<?>) is correct but creatorOf(T) is preferable. TBD - depends on usage patterns, specifically whether Lookup impls call these methods on the "wrong" pairs. Related to that, wondering why an instanceOf impl would ever return something other than c.isAssignableFrom(getType()). Is there some additional meaning to this method? Are there circumstances where getType() is expensive but instanceOf(Class) is cheap (FolderLookup perhaps)? Is getType() required/expected to return the concrete impl class (i.e. maybe a subclass of T) or can it just return T.class? Adjusting summary since Lookups.lookupItem is OK now, just talking about Pair<T>. And lowering priority since there are not many Pair subclasses outside of openide/util to my knowledge; most people would use Lookups.* factories or InstanceContent. I guess I send an answer to your last question via email and I somehow feel there is not much to do about our current state. FolderLookup.Item does handle instanceOf differently than getType(). I admit I am not 100% sure about creatorOf, especially because there is just one usage of it in AbstractLookup, but the javadoc correctly says what I meant - if the pair created an instances and it is == then the pair is creator. I believe that for usage of == the current types are more than appropriate. |