Talk:End Of Life Procedures

From APIDesign

This section is good, and reminiscent of (symmetric to?) your section at the beginning of Part 3, "An API Must ...".

One thing I would recommend: an additional section of this chapter about communicating and distributing one's API. In my experience, a number of people have developed APIs which may be either good or bad, but which I have little chance of knowing, because it's presented so badly as to discourage me from investigating further, thereby rendering all of the work that went into the API somewhat useless. I know this isn't purely a software thing, but I think communicating an API clearly - what it does, what its limitations are, how it works!!! - is very important.

--Dmkoelle 02:56, 23 April 2008 (UTC)

"... but also whole packages like java.beans.beancontext that are there without any further reason." Why? This package has not been deprecated AFAIK and it may still be quite useful to some.

--TomWheeler Wed Apr 23 20:38:48 CDT 2008

what is "paste jewelry"?

--Richunger 05:23, 26 April 2008 (UTC)

Done: 646c80dd9887

"it is enough to specify a trigger ModuleAutoDeps": probably incomprehensible for non-NetBeans developers.

--AndreiBadea 13:16, 23 April 2008 (UTC)

In the TopManager example it would perhaps make sense to mention that you want to remove TopManager.

--AndreiBadea 13:18, 23 April 2008 (UTC)

The section on bytecode patching doesn't add anything here.

I was looking for more from this section. The example of TopManager delegating to ExecutionEngine.getDefault() seems pretty obvious, but I am interested in how you disentangled, say, MDR from the editor APIs. How do you identify segments of a large block of code that should be separated out into a module, and what methodology do you use to pull the strands apart and "API-ify" it?

--Richunger 05:27, 26 April 2008 (UTC)