|
Authored by: NigelWhitley on Friday, April 27 2012 @ 08:01 PM EDT |
I don't see the point you're trying to make. The term API is generally used to
describe one of two things (Oracle tend to alternate between them without making
it clear which they are talking about). One can talk about an API as the
specified set of methods and variables which allow one to access the internals
of the library (that would be the catalog or more accurately the Dewey system).
Alternatively it can refer to the whole library i.e. both internal code and the
publicly defined interface to that internal code (the catalog and the books).
In order to "enhance our interaction with whatever
is on the inside" you would need to alter the design of the API, not just
the code within it (which is the analogy I was drawing with the
"implementation" details of the book).
With respect, it's not nit picking to notice that a catalog for a book library
isn't exactly like an API for a code library - it's just missing the point of
the analogy. There are indeed lots of ways in which a book library differs from
a code library. For example, a book catalog might be expected to give the
publication date, author's name, language but these are unlikely to be included
in the API methods for a code library (although it's possible someone could
design it in such a bizarre fashion). I don't see how that helps anyone to
understand Oracle's or Google's position regarding the Java APIs.
------------------
Nigel Whitley
[ Reply to This | Parent | # ]
|
|
|
|
|