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