|
Authored by: bugstomper on Friday, April 27 2012 @ 09:46 PM EDT |
Dr. Mitchell was not helpful in his refusal to accept the filing cabinet
analogy. "Packages, classes, methods, and implementation are not like a
filing cabinet, drawers, folders, and the contents of the folder. They are more
like packages, classes, methods, and implementation."
As Robert Browning might have said "A man's speech should should exceed his
grasp of the literal or what's a metaphor?"
The filing cabinet, drawers, folders, and contents are a great analogy, if you
extend it to allow drawers to be able to contain nested drawers to an indefinite
depth. Google should have used Dr. Who to rebut Dr. Mitchell, with an
explanation like
http://www.youtube.com/watch?v=pvnKXOGYKM8
I think an explanation like that would have fit perfectly with the rest of the
analogies and explanations presented in this case.
(For the fans, yes I do know that he is The Doctor, and it is only the show that
is called Dr. Who, but this is being read by laypeople, more likely to
understand when they read "API packages" and "Dr. Who"
instead of the more precise terms.)
[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Saturday, April 28 2012 @ 01:23 AM EDT |
You over-complicate it. A package is a directory (or folder) with
class files and/or other folders inside it. The fully qualified package name is
then essentially a path
in order to guarantee uniqueness of names. In this
way, nouns
which have meaning in multiple domains, such as Document, may be
contextualized by
the placement in different packages. A file drawer is
a good analogy
for the java implementation of the package, though not perfect,
as file drawers
don't have file
drawers, so I recently delivered a project
that had this package (pardon the
anonymizing, I'm sure you'll understand that
I wouldn't presume to bring my
clients into this conversation)
top-level-
domain.institution.department.server.application-name.base.session
and in
that package were interfaces, abstract and concrete classes, and helper
classes
related to a session happening in real time and to be analyzed later
after being
recreated from the log of events.
Each name represented a folder
within a folder, so the depth was 7. (The top
folder above was called src which
was in a folder Base because these were
the business level objects. Another
folder was called Application and this is
where I put the Model-View-Controller
classes of the various graphical user
interface windows. Note, java does
not allow a class to be defined
across two
files, but other java-esque
languages aren't as restrictive. [ Reply to This | Parent | # ]
|
|
Authored by: Ian Al on Saturday, April 28 2012 @ 09:41 AM EDT |
I want to start with why I think it is important. With a registered anthology,
the selection and organisation is important, but not the content of the items in
the anthology. With a registered collection, only the selection is important and
not the content of the items in the collection. With an individual document
registration (like a book) it is the creative expression fixated in the book
that is important.
Now the question. Is each of the 37 asserted library packages packaged in a
single file? I want to ignore distribution tricks like zipping and archiving. Is
the package, itself, a copyrightable document in its own right?
If Oracle have a registered copyright on a compilation of packages, they may not
have any protectable copyright stuff identified if each package is not a single
copyrighted item.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Saturday, April 28 2012 @ 11:10 AM EDT |
...enough to make anyone socially awkward.
with apologies[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Sunday, April 29 2012 @ 08:51 AM EDT |
Why aren't the lawyers using the metaphor/
analogy that an API is like a legal contract where
the nitty gritty details (blackbox implementation)
are at the discretion of parties. A lease may call
for the landlord to clear the parking lot of snow --
it doesn't say exactly when, how many snow
plows, or if it'll be done manually instead.
When you draft a contract, rarely do you start
from scratch. You cut & paste from similar ones,
draw on past experience, collaborate with others,
etc. It's very derivative.
Contracts have evolved where SSO, terminology,
and verbiage is expected. Diverge and suffer
ridicule from your peers.
[ Reply to This | Parent | # ]
|
|
|
|
|