Proposed improved decorator syntax

[Bruce Eckel]

Thursday, August 5, 2004, 6:54:56 PM, barnesc at engr.orst.edu wrote:

> Recognize that we're *really* trying to create function metadata. A more
> flexible solution is to make a metadata dictionary be part of function and
> class definitions.  Then 'decorator' simply becomes one name among many
> different metadata names.

I have to say I find this argument compelling. I can't say whether the
syntax works well, but if the fundamental problem is metadata, then
solving that in a way that solves all aspects of metadata is
desireable.

That said, I observe that this seems to be a fairly new topic for
many, including myself; I have some grasp of Java's metadata facility
and less of C#'s (although I understand C#'s to be more limiting than
Java's) and I have not read anything terribly in-depth about either.
It reminds me of my first exposure to C++ templates many years ago --
it seemed like there was a lot more to it than meets the eye, but it
took me years to really start to grasp what it was about (by
understanding latent typing via python).

One thing that has come up in Java is that metadata has been suggested
for use in implementing a version of aspect-oriented programming,
another feature I've been struggling to understand. The one thing
about aspects that has occurred to me is that macros seem to be trying
to solve a similar problem (changing code behavior across the code
base), as do metaclasses. Same problem, very different approaches and
degrees of effectiveness. Things like the implementation of
'synchronized' is more aspecty than it is metadata; it is implementing
behavior changes rather than just attaching information to something
(the original intent of metadata; in Java you must generally write
additional code in order to add behavior based on a metadata tag).

I suppose the question, then, is this: what is the true intent of
decorators? Is it for code behavior change, or metadata, or both? If
it is for code behavior change, how do I hook into that with my own
code; if I wanted to implement, for example, logging upon entry and
exit of a method (the classic AOP example) or to begin and end a
transaction upon entry and exit of a method?

For that matter, should we limit the syntax of decorators to always
being at the beginning of a method? True aspects allow you to put a
cutpoint at any point in a method; perhaps decorators shouldn't be
restricted (even if we choose not to implement these ideas right
away).

These issues are tricky but they could be very powerful. And this
conversation is sounding an awfully lot like some of the language
design stuff that happened in the C++ committee. Some members decried
this, saying that the committee should only be codifying existing
features, but I think it was very necessary for these things to be
tried, even if they didn't always work out.

And I think we may be at a point where only experimentation will tell
us what works and where this thing needs to go. No one has enough
experience with it -- although some might argue that this is the
reason we shouldn't put it in at all, I think that it means we need to
try something out and iterate as we learn.

I don't know if "experimental features" have been put into the
language before, ones that actually exist in a release but have
warnings on them that say "things may change as we learn more." But if
not, it seems like this might be the time to start. I think we need
something to express metadata and/or code behavior change and/or
whatever it is that we're really trying to do, but I don't think we'll
figure out what that is until we have something to experiment with --
and change.

Bruce Eckel