J2 paper 0.2.1

[Paul McGuire]

"Robert Brewer" <fumanchu at amor.org> wrote in message
news:mailman.2201.1093271860.5135.python-list at python.org...
Colin J. Williams wrote:
> One nit picking comment on Robert Brewer's document: An
> annotation is a
> transformation of a function, as a change to the flow of control is.

I'd like someone to analyze that further. "Transform", like the word
"change", can mean almost anything in English. However, I find the use
of the term in programs to generally mean either coerce/convert/cast
between types, or some other mechanism whereby one object is supplied,
and another object returned. That is, "transform" affects Being/"is" as
opposed to Attribute/"has".



(sorry about the double post - damned newsreader!)

I saw this earlier and meant to comment on it.  How does annotating a
function transform it?  Does adding a docstring or ascribing authorship
change the function's behavior or logic?  Do you mean "annotation" in the
Java or C# sense?  If so, I think you are correct.  But I chalk this up to
those languages' poor use of the term "annotation."  I think Robert is using
"annotation" in the more general conversational sense.

If you interpret "transform" to mean "change in any way," well then it is
hardly a meaningful term to use for categorizing types of changes.  I read
Robert's use of "transform" to mean specifically "change the
logic/behavior/interface", whereas "annotation" refers to commentary,
version, copyright, or other notational attributes.  (I could contrive a
very narrow example, in which code logic may branch depending upon the value
of __version__, but this is a stretch.  More likely, code in the *caller*
may change depending on __version__, but then this would be a transformation
of the *caller*.)

I think Robert cites a useful test.  Things like synchronize, memoize,
staticmethod all extend the behavior of the embedded function, thereby
transforming it to lock, cache results, or change interface, *AND* a
different object is returned.

However, annotations such as author, version, and copyright merely add
attributes to the function, but do not need to return a new object.

I would not include preconditions or postconditions or argument type
checking into either of these groups by the way - while they do change
behavior (by adding checking code), I think they are their own special case
of "transform", that are specifically oriented to defining assertions to be
met (without cluttering the code of the embedded function).  Maybe instead
of "transformational" they could be called "assertional."

My $0.02,
-- Paul