On Oct 22, 3:02 pm, James Harris <james.harri...@[EMAIL PROTECTED]
>
wrote:
> On 19 Oct, 19:23, rem6...@[EMAIL PROTECTED]
(Robert Maas,
seehttp://tinyurl.com/uh3t)
> wrote:
>
> > > From: James Harris <james.harri...@[EMAIL PROTECTED]
>
>
[]
> > and for OO method or named package you'd just drop the "mkvl"
> > prefix since that's redundant with the package name or class name:
> > Lisp package: (setq animals (mkvl:make)) (mkvl:put animals "Carp"
"Fish")
> > Java class: Mkvl animals = new MySuperHashTable(); animals.put("Carp",
"Fish").
> > where MySuperHashTable implements the Mkvl interface, for you Java
experts.
>
> > So I want the self-documenting code and the comments and formal
> > documentation and discussions/advertisements to all use the same
> > easy-to-grok jargon.
>
> Understood. I'm curious to find out what you finally choose. You'll
> have to let us know.
Robert,
It might help to know a phrase I have used for many years which is
Self-documenting code isn't.
Normally I use this in the context that code can only tell you what it
does (the implementation), it cannot tell you what it should do (the
requirements). I think you might be overreaching for a easy term for
all those contexts. An abstract data type is abstract for a reason.
The functionality (look up a value for a given key) can be very
different from the implementation. just define the functionality in
the comments and design document, pick a term to associate with that
for your context and move on.
Ed
|
