Re: Re: project conversion questions
Peter Wisnovsky <[email protected]> Thu, 31 Jul 2003 09:44:00 -0700
| Newsgroups | gmane.comp.java.netbeans.modules.projects.devel |
|---|---|
| Message-ID | <[email protected]> |
Svata Dedic writes: > On Thu, 2003-07-31 at 08:23, Tomas Zezula wrote: > > The content of CookieSet or Lookup (which is now preferred) should be > > described in the documentation. > > If it helps, not only NetBeans has this problem. I am now working with > Eclipse - and they put implement IAdaptable interface (a subset of > Lookup.Provider - no change notifications, or multiplicity) on a number > of classes. One never knows what are all options - and they vary > depending on what plugins are in the system. This, for example, is the > doc for IEditorInput.getAdapter() API method: > "Editor input must implement the IAdaptable interface; extensions are > managed by the platform's adapter manager." > > :-( > > The problem is that the range of adapters (cookies) cannot be documented > in doc of the class that contains getCookie() - it is not known for that > class (otherwise there should be getters, anyway), they are add-on > services. > > Any idea how to organize documentation, so that you can find what > cookies are injected by various subsystems to a particular class' Lookup > ? Hmm...I'm all for implementation delegation but there is no language-level idiom in Java to express that there are different contracts implemented by an object other than interfaces. Cookies generally seem to oblige the consumer of an object to understand how the object implementation delegation works. This is not dissimilar to Microsoft COM, which also imposes a delegation system on top of other languages, but it is even less idiomatically C++ than cookies are idiomatic Java. However, COM does have a tool "OLE Spy" for analyzing the registry of types and their interfaces, whether implemented intrinsically or through delegation. Perhaps if the distinct types and their cookies were browseable in the (now unbrowsable) default system filesystem in a "type" extent this would address these needs. This would require that there be a design-time introspection of these objects, of course. Peter