Simple library

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (19:08, 12 May 2012) (edit) (undo)
 
(9 intermediate revisions not shown.)
Line 1: Line 1:
-
Some libraries, let's call their example a [[simple library]], have just one implementation. �The designer that defines what the [[API]] should do also implements it. Obviously, the [[proximity]] between the [[API]] and the [[ProviderAPI|provider of the implementation]] is almost zero - it is the same person.
+
Some libraries, let's name them [[simple library|simple libraries]], have just one implementation. The designer that defines what the [[API]] should do also implements it. Obviously, the [[proximity]] between the [[API]] and the [[ProviderAPI|provider of the implementation]] is almost zero - it is the same person or the same team.
-
Simple [[library]] are usually self contained. They contains the [[API]] as well as the implementation. Examples include most of '''java.util''' package, or {{JDK|java/lang|Math}} class. Of course, there may be some attempts to re-implement these libraries (like GNU Classpath or Harmony), but those are licensing driven efforts, not technical ones. In general, there is little to no reason to re-implement such libraries.
+
Simple [[library|libraries]] are usually self contained. They combine the [[API]] specification together with the implementation. There is no reason, no way to plug into the library and change the way it behaves (for other [[ClientAPI|clients of its API]]). Examples of such [[simple library]] include most of '''java.util''' package (with classes like {{JDK|java/util|ArrayList}} or {{JDK|java/util|Collections}})), or other utility classes like {{JDK|java/lang|Math}} class.
 +
 
 +
Of course, there may be some attempts to re-implement these [[simple library|simple libraries]] (like [[GNU Classpath]] or [[Harmony]] show), but those are usually licensing driven efforts, not purely technical ones.
 +
 
 +
Especially when the [[simple library]] is available as [[open source]]. It is much easier to contribute back than to fork. If there is some flaw in the library, it seems easier to create an [[API Patch]] and donate it back to the [[simple library]] owners. In general, there is little to no reason to re-implement [[simple library]] [[API]]s.

Current revision

Some libraries, let's name them simple libraries, have just one implementation. The designer that defines what the API should do also implements it. Obviously, the proximity between the API and the provider of the implementation is almost zero - it is the same person or the same team.

Simple libraries are usually self contained. They combine the API specification together with the implementation. There is no reason, no way to plug into the library and change the way it behaves (for other clients of its API). Examples of such simple library include most of java.util package (with classes like ArrayList or Collections)), or other utility classes like Math class.

Of course, there may be some attempts to re-implement these simple libraries (like GNU Classpath or Harmony show), but those are usually licensing driven efforts, not purely technical ones.

Especially when the simple library is available as open source. It is much easier to contribute back than to fork. If there is some flaw in the library, it seems easier to create an API Patch and donate it back to the simple library owners. In general, there is little to no reason to re-implement simple library APIs.

Personal tools
buy