|
|
|
| Authored by: Anonymous on Friday, May 04 2012 @ 04:17 PM EDT |
It's a bit confusing, but usually (in the C++ world anyways)
you have a class definition that includes declarations of
individual functions and member variables that themselves are
implemented in a distinct file.[ Reply to This | Parent | # ]
|
| |
| Authored by: rcsteiner on Friday, May 04 2012 @ 04:26 PM EDT |
The API is the agreed-upon concept of name(arguments) for a given case.
The writing down of the "name(arguments)" constructs is either
documentation or code, not the concept itself.
If I say you must do the following in language X:
FOO (int bar, int baz)
I am documenting the API call in an informal manner, but the API itself is the
specific concept of the above FOO call and its format.
A programmer knows what to do, and will write code and/or formal documentation
as required.
---
-Rich Steiner >>>---> Mableton, GA USA
The Theorem Theorem: If If, Then Then.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, May 05 2012 @ 01:06 PM EDT |
It's the same on a level and different on another level, hence the difficulty in
being clear. Specifically, those elements *as a concept* would be an API; those
elements *as an expression* would be documentation (or declaration, depending on
context). The documentation *could* include more than those elements, but would
need to include at least those elements to properly document the interface.
Note that such a lowest-common-denominator definition may not always be fair and
appropriate, because context is critical to being able to say anything concrete
about an abstract concept. Fundamentally, an API is the concept of harmony in
communication, that is, both sides agreeing on *how* to communicate, as applied
to programming. It can be construed more broadly or specifically based on
context and what the speaker wants to convey; a protocol, for instance, would
not normally be considered an API, but if you used it to implement an RPC
interface? There's probably an API there. Different programmers may even
disagree on the distinction between 'linking' and 'communicating at arms length'
in some cases, because there is an inherent similarity there that's easy to
recognize, and the differences are somewhat nebulous. (The Linux kernel provides
an interesting example, since they provide public interfaces and 'internal'
interfaces, and actually predicate license-related decisions on it. There is
even some disagreement among kernel developers about which interfaces should be
appropriate for non-GPL-compatible code; the principle that is mostly applied in
the decision relates to a value judgment on genericness/intimacy: if
understanding the meaning/use of the interface requires intimate knowledge of
the internals of a driver, firmware, hardware interface, etc. it's not a public
interface; if it provides something generically understandable/usable to a wider
audience it's public.)
Semi-tangentially, I'm reminded of a discussion I saw on LWN recently where
someone was talking about how the ability to accept meaninglessness was critical
to understanding programming...[ Reply to This | Parent | # ]
|
|
|
|
|
