|
|
|
| Authored by: rcsteiner on Friday, May 04 2012 @ 02:45 PM EDT |
APIs are not a complex topic.
The concept is trivial, but it becomes easily overshadowed by noise when
technical experts start becoming pedantic and forgetting the context of the
discussion at hand.
Based on what I have read here, I would speculate that some of the technical
experts in this forum have a fair amount of experience, but for many that
experience appears to be focused on a fairly small subset of technologies (say,
only C-like languages, or only OO languages).
That focus (or less politely, that limited perspective) sometimes creates
unnecessary complexity.
The KISS principle applies here as it does to anything else. In my mind, if the
definition of "API" won't work for a fairly simple language like
Fortran, which is still in fairly heavy use in a number of scientific and
business contexts, the definition is simply not an accurate one.
An API is the definition of how you invoke a routine (or function, or object, or
primitive, or ER, or whatever you want to call it in your own local dialect).
Full stop.
1. Entity name.
2. Argument order.
3. Argument types.
Anything else is unnecessary context which tends to be tool specific in nature.
IMO.
---
-Rich Steiner >>>---> Mableton, GA USA
The Theorem Theorem: If If, Then Then.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 04 2012 @ 03:06 PM EDT |
Even technical experts here on this site -- including professional programmers
with 20 years or more experience -- have not been able to agree on a clear
definition of what an API is. And none of us have much experience with SSO of
copyrightable works. Mix the two together, and the result is a mystery cocktail
that nobody (not the Judge, not the lawyers for either side, not even their
expert witnesses) has been able to clearly articulate. The best we have is
analogies and "conceptual overlap".
Speak for yourself, mate.
I am one of those "professional programmers with 20 years or more
experience" - Ive even designed and implemented APIs and Im telling you
here and now API's are neither complex to understand (once you are skilled in
the art) nor a creative work.
The fact that a few Oracle "witnesses" will shill and say otherwise
makes no difference.
The "analogies and conceptual overlaps" you speak of are put there so
that the nai'ive can share the knowledge without having to go to API school for
10 years.
Oracle is at it, plain and simple. And if they prevail it will f**k things
royally up for us "professional programmers" for a long, long time.
Trust me.
Im not saying Google hasn't been a bit sharp here but Sun opened the bottle and
the Java Genie is out. Oracle can stamp their wee feet all they want. They spent
7.4b on something that isn't worth s**t and their egos won't let them come to
terms with it.
[ Reply to This | Parent | # ]
|
| |
| Authored by: eachus on Friday, May 04 2012 @ 03:51 PM EDT |
| Can I define what an API is? Sure, that is fairly trivial with respect to any
programming language I know. The problem is that the definitions are different.
Not only is the information in an API different, and arranged differently, for
different languages, the conceptual structure is different.
Worse,
some languages have multiple API definitions. For 90% of Ada programs, very
little information is needed in the APIs about tasking behavior and timing.
Write hard real-time code (where too late is another way of saying
wrong) and you will use a specialized set of tools to communicate timing
information as a part of the API. (There is a convention for naming packages to
show tasking/threading behavior that should be considered part of the "standard"
APIs. For most APIs that information is unnecessary. i.e.
Ada.Containers.Synchronized_Queue_Interfaces defines a queue type that blocks
waiting for input in another thread instead of returning an error. That
information is required to use a queuing package correctly. For any API that is
called by a single thread though, whether or not the body of the package
creates additional threads is not part of the API.)
Speaking specifically
of Java, though, the definition of an API in Java is made much more difficult by
the fact that class and method declarations are mixed with the implementation
code, including classes and methods that may not be part of the API. In Ada
subprogram (method) declarations are repeated in the body of a package to make
reading the implementation code easier. When Ada was new, that was questioned
as being too verbose, but for implementers it is easy to start by cutting
and pasting, or just copying the entire package declaration and editing out (or
commenting out) the bits that don't belong in the body. ;-) Types and other
declarations in the package body, or in the private part of the package
specification are clearly marked as not visible to users of the package.
[ Reply to This | Parent | # ]
|
|
|
|
|
