|
|
|
| Authored by: Anonymous on Saturday, April 21 2012 @ 02:41 AM EDT |
| Implementation = set of code used by a program to do something. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 02:44 AM EDT |
>> I would agree that if you protect the Java APIs, then no one else can
use
Java without Sun giving the OK.
'Using Java' and 'implementing java' are very very different things.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 04:44 AM EDT |
PJ - here's my shot.
Every computer language has a fixed internal list of simple functions built in -
these are called primitives.
In a hypothetical dialect of BASIC (call it BASIC-Z), these could be: EDIT, RUN,
LIST, LET, GOTO, CONTINUE, INPUT, NEW, REM, PRINT, STOP in INPUT data, BREAK,
FOR, NEXT, TO, STEP,GOSUB, RETURN, READ, DATA, RESTORE
These can be thought of as an internal library - though it has no name.
Each primitive has it's calling convention - LET, for example expects a
declaration like a=b+8, LET "andrew" produces an error, as does an
undefined "b" - this calling convention could be thought of as an
API.
Now, you can do a lot with primitives but it is extremely tedious. Most
programs are terribly repetitive, at various times you want to perform the same
operation over and over again - if there isn't a primitive for that operation
then to save time and typing you encapsulate it in a subroutine that you can
call anytime you want to do that operation again. A subroutine is a
logico-mathematic construct.
"Oh gosh, here I am wanting to convert a Gregorian date to to an Islamic
date again. I know, instead of wrting the whole routine out all over again I'll
declare it as a subroutine and then whenever I need to do it again I'll just
send the Gregorian date to the conv_date_Islamic and get the Islamic
date!"
conv_date_Islamic will have it's API - it may for example, expect the date sent
to it to be formatted MM/DD/YYYY, so if you send it a date as DD/MM/YYYY it'll
give the wrong answer!
So gradually as a programmer you built up a library of subroutines that do
useful things.
Lets call my library lib.date_conv - it has a name and contains a variety of
subroutines that do useful things. So lib.date_conv has let's say 34
subroutines in it with names - conv_date_Budd, conv_date_Islamic,
conv_date_Armenian, etc. Each of these will have it's own API, just like
conv_date_Islamic.
Time goes by and I find that I have lots of libraries, lib.date_conv, lib.stats,
lib.math and so on.
Suppose my friend is a neophyte programmer and moaning to me what a chore it all
is - I can say to him/her, "Don't stress, I've worked it all out before,
I'll give you my library for date conversion"
Eventually, I bundle up all my libraries and make then available for download as
andrew's lib_collection under what ever licence I choose.
Now let's note a few things:
1) There is nothing to stop Jim Someone from implementing a library like
lib.date_Islamic of their own (better or faster) and making it available.
Internally it'll look a lot like mine, because there are really only a few ways
of converting Gregorian dates to Islamic dates. Jim can even use the same name
for the library (whats in a name?) though he could call it lib.Islamic_date.
But if he is going to use my name of lib.date_Islamic then he would do well to
keep the calling APIs the same otherwise someone who uses his (better, faster or
different)version may get unexpected results!
2) Some functions that I have/would like to have in my library may be awfully
hard or clumsy to implement just using the provided primitives. So maybe I'll
choose to write them in a machine code or C or whatever. They'll still have to
have an API of course and if I want them to substitute for a function written
using primitives (but give the same result) I'll have to make sure that the APIs
are the same.
3) The primitives of a different dialect of BASIC, say BASICA rather than my
BASIC-Z, may be different, for example, they may require 3 arguments passed to
then rather than 2. So a subroutine (function) that works in BASIC-Z may not
work in BASICA. My libraries may not work in BASICA unless I've been careful
and allowed for it.
Now if I can't copyright a language, how can I copyright a library for that
language, (particularly if the library is written IN that language)?
Mac the Cutterman
[ Reply to This | Parent | # ]
|
| |
| Authored by: Winter on Saturday, April 21 2012 @ 08:09 AM EDT |
An API is just a standard, like Meter, Kg, Seconds. Or ISO 9000. It tells you
the name and meaning of an entity and how to determine whether you have it
correct.
Writing an API is difficult because you need to square your own views with those
of the (future) users.
And, also, an API in programming terms *is* a header file.
---
Some say the sun rises in the east, some say it rises in the west; the truth
lies probably somewhere in between.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 08:32 AM EDT |
I see a API somewhat as what to do, the code as how to do it.
If people tell each other what they want, they have lot's of non
verbal ways to communicate. And the context may tell a lot.
But with programming, you have to be very meticulous in telling
how, or things go wrong. But it is still just communication, you
need it also to solve the problem, but the problem is not solved
without the code.
And I admit, part of the possibility's of the code can be
mirrored in the complexity of the API. And some of that may be
original. Just like the complexity of our thinking will be
mirrored in the language we use.
Not all languages had words for zero, not even for bigger
numbers. People think of new concepts all day. And give them
names, that can reflect part of that originality. Will we now
have to take a licence before we can name new things?
Everybody would agree this would be complete nonsense. And this
shows there has to be a boundary, there is a limit of what can be
protected. Just establish that some originality is also found in
the used words should not be enough to protects those words. Is
that different for an API?
And it can well be understood that trying to move that boundary
for the interest of a party scares many in the programming world.
As it would have scared a lot of us if someone would have told us
a "netbook" is my idea and you may not use that word or any word
that describes that kind of product without paying me.
If Oracle/Sun was on one hand trying to get compensated for the
remarkable efforts they did in developing Java and on the other
hand was giving things away, it should have done a better job,
build a better legal framework in the first place. Instead of
trying to move that boundary now.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 09:13 AM EDT |
Based on the waiter/customer example in a restaurant, we
could make the analogy even simpler (but it is an analogy
only):
- The restaurant's menu is the API that both the customer
(programmer) and the waiters/chefs (implementation) know.
- The customer uses the "words" in the menu to order
something (asking for a "function")
- the chefs/waiters do the cooking/get the wine, etc
(performing the functions)
Given the fact that many restaurants offer a similar set of
meals you'll find similar (sometimes even same) menus
(API) in different restaurants (programming languages /
environments). The words (Schnitzel, Hamburger, ...) and the
structure of the menus are not protected. The
"implementation" (the meals) may differ in quality, similar
to computer functions that may differ in execution speed for
example.
Would this make sense as a _very simple_ analogy?
Regards,
Werner[ Reply to This | Parent | # ]
|
| |
| Authored by: sdm on Saturday, April 21 2012 @ 09:27 AM EDT |
The Starbucks 'language' is the body of words required for a coffee drinker to
get a coffee from Starbucks. Tall, Grande, Short, Caramel Macchiato, etc. If you
want a coffee from Starbucks, you must use these words. The Tim Horton's coffee
language is different but still similar.
To get a coffee from Starbucks, you must use the CPI (Coffee Purchaser's
Interface) and it is through this interface that you supply the information so
that the machinery in the back can make your drink. There is a pretty
sophisticated help subsystem built into the Starbucks CPI that helps you select
the proper drink and organize the parameter list into the form expected by the
machinery. I like to have an americano but with less water so I approach the CPI
and ask for, "An americano please."
Now there is an item on the list of available drinks that matches 'americano' so
I have properly supplied the first required element to the CPI. However, there
is a parameter list to be filled; size, number of shots, amount of water. So we
work our way through this until the CPI turns to the left and says, "Tall,
3/4 full, extra shot, americano." And a few minutes later my coffee appears
and I have successfully used the Starbucks CPI. Someday I will remember the
proper parameter list order and make accessing the CPI more efficient but I get
by...
If I can't find a Starbucks, my fallback position is to go to Tim Horton's but
this requires a slightly different language, parameter list and parameter order.
I'm not even sure if americano is on the function list so I order a coffee.
Timmy's is interesting because some of the functions can be called by inference;
you don't even need the function name. "I would like a medium double double
please." That is, a medium sized coffee with two cream and two sugar.
If the Starbucks coffee language was free for all to use then we could approach
a compatible coffee shop and use it with that particular CPI knowing that it
would be implemented in the back to produce my coffee even though that actual
implementation method might be different.
At Starbucks, the CPI is where I utter the proper words to get the desired
result. I would argue that the list of functions and parameters required for me
to get my coffee from Starbucks is not that interface. I can look up and see
that list and I use it to form my request but that request must go to the CPI
because that is the mechanism I must use to get anything at all from them.
Cheers,
[ Reply to This | Parent | # ]
|
| |
| Authored by: Tinstaafl on Saturday, April 21 2012 @ 11:29 AM EDT |
I need a device to perform a task. Could be any task but lets say I need a
module to measure speed and display it. I could build something that will do the
job, or I could make use of one that someone else has built. There might even be
a choice of devices, some built do the job quickly, others more accurately,
perhaps some are optimised for power use while others are made to require little
space. However, they are all built to do the same job, using the same signals
in, work on the signals and then output the result.
It doesn't much matter how it's done, as long as I know how to activate it, what
signals/information/data I have to supply (and in what order & format) when
it's switched on, and what/how the result will be made available.
Think of a speedometer in a car. It's a device that is switched on by having the
various cables connected using the correct connectors, it requires certain
information from sensors on the car sent to it by some of the connectors, and
then it outputs a speed for us to read, calibrated to a certain measurement
system. How the speedometer does its magic inside the box matters little to us,
as long as the correct signals go in through the correct connections, and the
result gets displayed in the way that we're expecting. Connect the cables
wrongly then the speedo won't work as expected. That's the interface between us
& the device and is specified by the designer of that speedometer. I could
choose to build my own speedometer using the same cables & connectors ie the
same interface, from the vehicle and, as long as the internal working is my own
design, I'll not have copied someone else's design.
Much like an API and its functions. Shove the data in, in the way the API
requires, and get a result. What goes on hidden behind the interface is
irrelevant. Data in, in the correct way, answer out. Or even build my own
substitute functions requiring the same data in, in the same way and then
spitting out the answer. In other words, using the same API, but completely
different source code.
You can copyright your source code (its 'fixed'), but not the way the
information must be passed to it. I can copyright what I write but not how it is
accessed.
In another example, consider a book. It's the information content in a book that
is copyrighted, but not the book itself. The book is the interface to the
information. You can't access the information without using the interface
(Support the book, grasp the edge of the cover towards the right hand edge, move
the cover so that it is forced to pivot around its mounting edge against the
spine, look at the printing in the sequence of left to right, top to bottom
etc). The interface determines how you access the tool, but not what the tool
is.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Saturday, April 21 2012 @ 12:04 PM EDT |
Why does nobody bring up the car analogy for API's?
Turn the steering wheel to make turns. Use the gas pedal to
increase speed, use the brake pedal to decrease. That's
your interface.
How it is implemented differs between brands and types of
cars. A normal car implements the gas pedal perhaps as
opening some kind of a valve to increase gas flow. A hybrid
or electrical car will implement the gas pedal as a kind of
electronic switch, with a computer controlling gas flow or
electric current to the engine.
The brake pedal may work by using your muscle force to push
fluid through a tube to operate the brakes. However, I once
owned a car in which the brake pedal controlled a valve of a
high pressure pneumatic system, allowing me to touch the
brake pedal very lightly yet brake very hard.
For all these different implementations, the interface for
the driver is the same: just push the pedal. Now imagine a
single car manufacturer claiming copyright on controlling a
car with a steering wheel and pedals...[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, April 22 2012 @ 01:10 PM EDT |
Two comments here:
1) API is Application Programming Interface. Its purpose is
to provide a standard way to programmatically interact with
some resource as a user/consumer of that resource, and may
also be used as the way to provide your resource or
implementation for others to access using the same API.
If you have a component/library/resource that you just want
to allow some other software developer(s) to use, it's a
pretty simple task to define the API through which a program
will interact with your component/library/resource.
If, on the other hand, you are defining a standard, like one
of the Java APIs, you put a whole lot of effort into it
precisely for the reason that you want a robust and, as much
as possible, an unchanging API for developers to use when
they create their applications. The effort is to ensure
that the API doesn't somehow limit the various
implementations that may be created, even future
implementations that may use technologies yet to be
developed. The effort is also to ensure it doesn't restrict
unnecessarily how an application can use the API. So Oracle
can correctly state that they put in a lot of effort
developing an API, but it would have been for the sole
purpose of making that API as robust and "usable" as
possible for developers to use when building their
applications.
2) The analogies of the airplane control panel and menu bar
fail because these are actually implementations. An API is
abstract. The control panel is NOT the API... the API
*describes* the control panel. The control panel itself is
still an implementation.
Same with the menu bar - although as an analogy, it falls
down faster since it involves interacting with a human. In
this case, the API might describe how there must be a
clickable area, identified in a way that the user
understands to mean "print", which initiates the printing
process when the area is clicked. What the user will
understand to mean "print" isn't precise like the name of a
method in a Java API, however. And this is where the menu
bar analogy falls down.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 27 2012 @ 01:19 PM EDT |
Rudder pedals, stick and throttle. Each has a defined
effect that it has on the airplane's control surfaces
and engines. There are lots of other little details
like trim control and flaps, landing gear, fuel controls,
but from the context of flying, the three biggies above
are most of what's used. The API would say:
"Push the throttle forward to increase engine output,
pull it back to decrease the engine output". Of course
each manufacturer has their own (possibly patented)
implementation details, but they all follow that model
of how the pilot works the throttle to get the desired
engine response.
"Push the stick to the left to get the plane to tilt left,
push it to the right to get the plane to tilt right".
Again, the stick could connect to the ailerons via
cables, hydraulic system, pneumatic, or "fly-by-wire"
for the implementation, but the API is the same in all
cases. The Airplane Pilot Interface (API) has to match
the specified guidelines or the plane will not be
certified.
[ Reply to This | Parent | # ]
|
|
|
|
|
